 |
 |
On Nov 19, 2013, at 9:54 AM, Aaron Rubinstein <[log in to unmask]> wrote: > I think you’ve hit the nail on the head here, Karen. I would just > add, or maybe reassure, that this does not necessarily require > rethinking your existing metadata but how to translate that > ^^^^^^^^^^^^^^^^^^^^^ > existing metadata into a linked data environment. Though this > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > might seem like a pain, in many cases it will actually inspire > you to go back and improve/increase the value of that existing > metadata... There are tools allowing people to translate existing metadata into a linked data environment, and for right now, I advocate that they are good enough. I will provide simplistic examples. For people who maintain MARC records: 1. convert the MARC records to MARCXML with the MARCXML Toolkit [1] 2. convert the MARCXML to RDF/XML in the manner of BIBFRAME’s transformation service [2] 3. save the resulting RDF/XML on a Web server 4. convert the MARC (or MARCXML) into (valid) HTML 5. save the resulting HTML on a Web server 6. for extra credit, implement a content negotiation service for the HTML and RDF/XML 7. for extra extra credit, implement a SPARQL endpoint for your RDF If one does Steps #1 through #5, then they are doing linked data and participating in the Semantic Web. That is the goal. For people who maintain EAD files: 1. transform the EAD files into RDF/XML with a stylesheet created by the Archives Hub [3] 2. save the resulting RDF/XML on a Web server 3. transform the EAD into HTML, using your favorite EAD to HTML stylesheet [4] 4. save the resulting HTML on a Web server 5. for extra credit, implement a content negotiation service for the HTML and RDF/XML 6. for extra extra credit, implement a SPARQL endpoint for your RDF If one does Steps #1 through #4 of this example, then they are doing linked data and participating in the Semantic Web. That is the goal. In both examples the end result will be a valid linked data implementation. Not complete. Not necessarily as thorough as desired. Not necessarily as accurate as desired. But valid. Such a process will not expose false, incorrect data/information, but rather data/information that is intended to be maintained, improved, and updated on a continual basis. Finally, I want to highlight a distinction between well-formed, valid, and accurate information — linked data. I will use XML as an example. XML can be “well-formed”. This means it is syntactically correct. Specific characters are represented by entities. Elements are correctly opened and closed. The whole structure has a single root. Etc. The next level up is “valid”. Valid XML is XML that conforms to a DTD or schema; it is semantically correct. It means that required elements exist, and are presented in a particular order. Specific attributes used in elements are denoted. And in the case of schemas, values in elements and attributes take on particular shapes beyond simple character data. Finally XML can be “accurate” (my term). This means the assertions in the XML are true. For example, there is nothing stopping me from putting the title of a work in an author element. How is the computer expected to know the difference? It can’t. Alternatively, the title could be presented as “Thee Adventrs Av Tom Sawher”, when the more accurate title may be “The Adventures of Tom Sawyer”. Well-formedness and validity is the domain of computers. Accuracy is the domain of humans. In the world of linked data, you are not participating if your published data is not “well-formed”. (Go back to start.) You are participating if it is “valid”. But you are really doing really well if the data is “accurate”. Let’s not make this more difficult than it really is. [1] MARCXML Toolkit - linked at http://www.loc.gov/standards/marcxml/ [2] BIBFRAME’s transformation service - http://bibframe.org/tools/transform/start [3] Archives Hub stylesheet - http://data.archiveshub.ac.uk/xslt/ead2rdf.xsl [4] EAD to HTML - for example, http://www.catholicresearch.net/data/ead/ead2html.xsl — Eric Morgan