I can hardly believe it's been eight months since I last wrote about the NISO I2 project. A lot has changed since then[1]. I continue to work on I2 however; they won't get rid of me that easily.

In the last post, I wrote:

The next step is to build upon the report to draw yet more conclusions from the data — there's an awful lot there — and flesh out some repository use cases for institutional identifiers. The I2 core group is moving quickly towards finalizing identifier metadata elements so that a standard may be drafted, and I think having some use cases documented will help drive the standard in a direction the community can get behind.

Since that time, the three scenario groups — Electronic Resources; Institutional Repositories and Learning Management Systems; and Library Resource Management — have concluded their work. The work of the scenario groups included surveys of over 300 people working in these fields. The survey results have been analyzed and reports were posted on the NISO website. These reports have been used to flesh out use cases for an institutional identifier. Upon completion of this work, the scenario groups were disbanded and work continued in a broader I2 working group.

The I2 working group has concentrated its work on analysis of similar standards and, as I alluded to earlier, significant effort has gone into defining core metadata to identify institutions, such as institution name, institution type, location information, variant identifiers, domain name(s), URL(s), and (optionally-typed) relationships to other institutions. During these discussions it was difficult for me to hear the issues and needs around I2's metadata and identifiers without linked data springing to mind.

While we are designing a standard and not a system or a service per se, it seems useful to include in the standard an informative section about implementation and architecture[2]; I find that reading standards is much easier on the brain when you get not only the standard itself but some examples of implementation, and that will be true as well, one hopes, of I2 standard implementers. To that end, the group will be producing an XML schema of the I2 metadata elements and also an RDF schema.

I have been working on the RDF for I2 on and off for the past month or two. Below are my impressions, as someone who is new to modeling in RDF, and the procedures I used to produce the draft RDF schema.

Despite their names, RDF schema and XML schema are quite different[3]. The XML schema is a tool for validating an XML-based document or record, and it's a common tool for modeling metadata in libraryland. Not so with RDF schema, where the notion of document or record is replaced by the notion of a set of triples. The focus in RDF is on the triple not on the document, and so validation of documents or records is not the point of RDF schema. This took some effort to wrap my mind around.

Before I modeled I2 in RDF, I sketched out a domain model of I2 by copying relevant bits of information from I2 documents and pasting them into a text editor. Then I put them into classes. In I2's case, the domain model contained three classes of things: metadata elements about an institution, relationships between institutions, and types of institution.

I gathered some examples of relatively simple RDF schemas and transformed them into the Turtle serialization format[4] for ease of reading, using them as a template for the I2 schema.

In the RDF schema (RDFS) specification, there are two classes of things in the domain model: classes and properties. If you are familiar with object-oriented programming, chances are you already grok this way of modeling, but otherwise, generally: a class is like a type and a property is an attribute. If I were to model myself in RDF schema, then, I might say I am in the class of human beings, and one of my many properties is having a particular birth date, and another is having been born in a particular city. The next step was to take the I2 domain model (metadata elements about an institution, relationships between institutions, and types of institution) and decide whether each thing was a class or a property. I decided that the former two were sets of properties and that type of institution could be modeled as a set of classes.

Having a conceptual model of I2 and how it fit into the RDF schema way of thinking about things, I wrote a simple ontology defining one RDFS class per type of institution, and one RDFS property per metadata element and one per relationship type. This would have sufficed as an ontology.

Exposing RDF-based resources on the web as linked data, however, represents an opportunity for metadata element-level interoperability at global scale. In order to interoperate with the existing corpus of linked data available on the web, I went through the new I2 ontology and looked for areas where I could re-use, or subclass or otherwise link to, classes and properties already defined in more widely-used ontologies. I realized at this point just how different coming up with a new XML document format was from writing an RDF ontology; whereas I might have wanted the former to be comprehensive and inclusive of every single aspect within the I2 domain model, my goal with the latter became to eliminate it (by trimming it down to only those bits which are not defined elsewhere).

Since the RDF ontology for I2 is not inclusive of the entire domain model, it seemed necessary to produce another reference document: a set of instances of I2 resources showing the mingling of new I2-specific classes and properties with well-defined classes and properties from other ontologies.

I shared rough first drafts of these documents and received very helpful feedback from some folks who are better-versed in this than myself. I've now incorporated their feedback into the latest I2 ontology and instance document. I hope to include both of these into a draft of the I2 specification which will go out for comment in the coming months. Here's the latest ontology and the latest set of instances.

Notes

1. I've moved and changed jobs, in fact
2. This practice seems more or less common in my (admittedly limited) experience, cf. the unAPI specification.
3. This reflection should come as little surprise since RDF and XML are different kinds of things: RDF is a data model and XML is a serialization format.
4. Using rapper, a nifty little tool.

I am not certain if this is a good idea or not, but I decided to set up a "work blog" as I set off on my new path as a digital library architect. The lines between this blog and that blog are fuzzy — most lines are, in my eyes — so bear with me. I've never been a prolific writer — it's always a chore, an activity I simultaneously want to do more of, and do better, and also struggle mightily with. (It's the public school education? HAR HAR!) But even so, the posts here may slow yet more. Or maybe that will be true of the new blog. We shall see.

I've found that microblogging has largely filled the blogging gap for me; I'm more comfortable, somehow, posting smaller, more easily digestible "thoughtlets" via Twitter/identi.ca/Facebook. Perhaps I've succumbed to attention deficit disorder, flitting from one tiny undeveloped idea to the next. It's probable but I digress.

If you're interested, you can follow along as I grapple with questions about digital library architecture. Comments are most welcome, both here and there, as always.

As I mentioned earlier, I've been learning about linked data in the context of dropping it into the World Digital Library project. I am hopeful we'll be able to deploy the RDF views[1] before too long. In advance of that, I thought it might be helpful to share a sample of what our RDF would look like. The RDF below represents the WDL item for the U.S. Constitution. I appreciate constructive criticism.

A few things to note:

• Mmm, Unicode.
• Item types are from the Bibliographic Ontology.
• Most of the properties are from the Dublin Core Metadata Element Set ontology, especially used where literals are objects rather than resources identified by URI.
• Where possible I dug up or found URIs and used the Dublin Core Metadata Terms ontology.
• An item is modeled as an aggregation of its constituent files, as defined in OAI-ORE. The notion here is that an ORE aggregation of an item, as expressed in a resource map which is discoverable via a link header in each item detail page, is a "whole" item, including all of its files[2], metadata, and translations.
• I'm also making light use of the NEPOMUK File Ontology to express that constituent files are files, and to be explicit about file sizes so that folks know in advance of retrieving it how large files are.
• Links out to DDC (Decimalised Database of Concepts), Lingvoj, DBpedia, and Library of Congress Authorities & Vocabularies (e.g., LC Subject Headings) are included where possible. [3] I'd be especially stoked to hear of other vocabs I might link to. The more linked the data, the better.
• The output below is Turtle for readability, but the application will offer up RDF/XML.

The data after the jump:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix nfo: <http://www.semanticdesktop.org/ontologies/nfo#> .
@prefix ore: <http://www.openarchives.org/ore/terms/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
 
<http://localhost/static/c/2708/service/00303_2003_001_pr.jpg>
    dc:format "image/jpeg" ;
    nfo:fileSize "259485"^^<http://www.w3.org/2001/XMLSchema#long> ;
    a nfo:FileDataObject .
 
<http://localhost/static/c/2708/service/00303_2003_003_pr.jpg>
    dc:format "image/jpeg" ;
    nfo:fileSize "267031"^^<http://www.w3.org/2001/XMLSchema#long> ;
    a nfo:FileDataObject .
 
<http://localhost/static/c/2708/reference/00303_2003_004_pr_thumb_item.gif>
    dc:format "image/gif" ;
    nfo:fileSize "56620"^^<http://www.w3.org/2001/XMLSchema#long> ;
    a nfo:FileDataObject .
 
<http://localhost/static/c/2708/service/00303_2003_004_pr.jpg>
    dc:format "image/jpeg" ;
    nfo:fileSize "233875"^^<http://www.w3.org/2001/XMLSchema#long> ;
    a nfo:FileDataObject .
 
<http://localhost/static/c/2708/service/00303_2003_002_pr.jpg>
    dc:format "image/jpeg" ;
    nfo:fileSize "245809"^^<http://www.w3.org/2001/XMLSchema#long> ;
    a nfo:FileDataObject .
 
<http://localhost/item/2708/about.rdf>
    dcterms:created "2009-08-10T18:11:25-04:00"^^dcterms:W3CDTF ;
    dcterms:creator <http://dbpedia.org/resource/World_Digital_Library> ;
    dcterms:modified "2009-08-10T18:11:25-04:00"^^dcterms:W3CDTF ;
    ore:describes <http://localhost/item/2708/about.rdf#item> ;
    a ore:ResourceMap .
 
<http://localhost/item/2708/about.rdf#item>
    dc:created "17 Septembre 1787"@fr, "17 de septiembre de 1787"@es, "17 de setembro de 1787"@pt, "17 сентября 1787 г."@ru, "1787年9月17日"@zh, "September 17, 1787"@en, """١٧ ايلول ١٧٨٧
"""@ar ;
    dc:creator "Constitutional Convention, United States"@en, "Convención Constituyente, Estados Unidos"@es, "Convention constitutionnelle, États-Unis"@fr, "Convenção Constitucional, Estados Unidos"@pt, "Конституционная Конвенция, Соединенные Штаты"@ru, "الاتفاقية الدستورية، الولايات المتحدة"@ar, "制宪会议，美国"@zh ;
    dc:extent "Manuscript (4 pages of parchment)"@en, "Manuscrit (4 pages de parchemin)"@fr, "Manuscrito (4 páginas de pergamino)"@es, "Manuscrito (4 páginas em pergaminho)"@pt, "Рукопись (4 пергаментных страницы)"@ru, "مخطوطة (٤ صفحات من الورق النفيس)"@ar, "手草本（4 页羊皮纸）"@zh ;
    dc:language "Anglais"@fr, "English"@en, "Inglés"@es, "Inglês"@pt, "Английский язык"@ru, "الإنجليزية"@ar, "英语"@zh ;
    dc:publisher "Administração de Registros e Arquivos Nacionais"@pt, "Archives Nationales et Administration des documents (NARA) des États-Unis d'Amérique "@fr, "Los Archivos Nacionales y Administración de Documentos (NARA) de los Estados Unidos de América"@es, "National Archives and Records Administration"@en, "Управление национальных архивов и документов"@ru, "الإدارة الأمريكية للوثائق والسجلات الوطنية"@ar, "美国国家文件与档案管理局"@zh ;
    dc:subject "Constituciones"@es, "Constituições"@pt, "Constitutional & administrative law"@en, "Constitutions"@en, "Constitutions"@fr, "Derecho constitucional y administrativo"@es, "Direito constitucional e administrativo"@pt, "Droit constitutionnel et administratif"@fr, "Politics and government"@en, "Politique et gouvernement"@fr, "Política e governo"@pt, "Política y gobierno"@es, "Конституции"@ru, "Конституционное и административное право"@ru, "Политика и правительство"@ru, "الدساتير"@ar, "السياسة والحكومة"@ar, "القانون الدستوري والإداري."@ar, "宪法"@zh, "宪法 & 行政法"@zh, "政治和政府"@zh ;
    dc:title "Constitución de los Estados Unidos"@es, "Constituição dos Estados Unidos"@pt, "Constitution des États-Unis"@fr, "Constitution of the United States"@en, "Конституция Соединенных Штатов"@ru, "دستور الولايات المتحدة"@ar, "美国宪法"@zh ;
    dcterms:DDC "342" ;
    dcterms:LCSH <http://id.loc.gov/authorities/label/Constitutions> ;
    dcterms:alternative "Constitution of the United States"@en ;
    dcterms:dateSubmitted "2009-05-07T06:45:21-04:00"^^dcterms:W3CDTF ;
    dcterms:description "1787 年 5 月 14 日，制宪会议在费城的议会大楼（独立厅）召开，目的是修订《邦联条例》。 由于开始时只有两个州的代表团出席，成员不得不一天天地休会，直到 5 月 25 日与会人数达到法定的七个州。 通过讨论和争辩，6 月中旬时明确显示大会与其修改现有的《联邦条例》不如为政府重新起草一份全新的框架。 整个夏季，代表们都在非公开会议中辩论、起草、重新起草新宪法的条款。 主要的争论问题包括要赋予中央政府多大权利、允许各州在国会中有多少个代表席位以及这些代表应该如何选举产生——由人民直接选举还是由各州立法人员选举产生。 这部宪法是很多人智慧的结晶，是合作政治运作和妥协艺术的典范。"@zh, "A Convenção Federal reuniu-se na Casa de Estado (Hall da Independência), em Filadélfia, em 14 de maio de 1787 para revisar os Artigos da Confederação. Em virtude de estarem presentes, inicialmente, as delegações de apenas dois estados, os membros suspenderam os trabalhos, dia após dia, até que fosse atingido o quórum de sete estados em 25 de maio. Através de discussões e debates ficou claro, em meados de junho que, em vez de alterar os atuais artigos da Confederação, a convenção deveria elaborar uma estrutura inteiramente nova para o governo. Ao longo de todo o verão, os delegados debateram, elaboraram e reelaboraram os artigos da nova Constituição em sessões fechadas. Entre os principais pontos em questão estavam o grau de poder permitido ao governo central, o número de representantes no Congresso para cada Estado, e como estes representantes deveriam ser eleitos - diretamente pelo povo ou pelos legisladores do estado. A Constituição foi o trabalho de muitas mentes e permanece como um modelo de cooperação entre lideranças políticas e da arte da condescendência."@pt, "La Convención Federal se reunió en la Cámara del Estado (Salón de la Independencia) en Filadelfia el 14 de mayo de 1787, para revisar los artículos de la Confederación. Debido a que las delegaciones de sólo dos estados estuvieron presentes inicialmente, los miembros levantaron sesión de un día para el siguiente hasta que se obtuvo un quórum de siete estados el 25 de mayo. A través de la discusión y el debate se hizo evidente a mediados de junio que, en lugar de modificar los actuales artículos de la Confederación, la convención prepararía un marco totalmente nuevo para el gobierno. Durante todo el verano, los delegados debatieron, prepararon y redactaron nuevamente los artículos de la nueva Constitución en sesiones a puerta cerrada. Entre los principales puntos en cuestión estuvieron cuánto poder otorgar al gobierno central, el número de representantes en el Congreso que se iban a permitir a cada Estado y la forma en que estos representantes debían ser elegidos, directamente por el pueblo o por los legisladores estatales. La Constitución fue el resultado del trabajo de muchas mentes y se erige como modelo de cooperación política y del arte del compromiso."@es, "La Convention Fédérale s'assembla dans la Chambre Législative (Independence Hall) à Philadelphie le 14 mai 1787, pour réviser les articles de la Confédération. En raison de la seule présence initiale des délégations de deux États, les membres ajournèrent d'un jour à l'autre jusqu'à ce que le quorum de sept États soit obtenu le 25 mai. Â travers les discussions et les débats, il devint clair dès la mi-juin que, plutôt que de modifier les articles existants de la Confédération, la convention allait plutôt ébaucher un cadre entièrement nouveau pour le gouvernement. Tout au long de l'été, les délégués débattirent, élaborèrent, et remanièrent les articles de la nouvelle Constitution, à huis clos. Les principaux points litigieux portaient sur la puissance à accorder au gouvernement central, sur le nombre de représentants au Congrès pour chaque État, et sur le mode d'élection de ces représentants - directement par le peuple ou par les législateurs de l'état. La Constitution fut l'œuvre de nombreux esprits et reste un modèle de coopération politique et de l'art du compromis."@fr, "The Federal Convention convened in the State House (Independence Hall) in Philadelphia on May 14, 1787, to revise the Articles of Confederation. Because the delegations from only two states were present initially, the members adjourned from one day to the next until a quorum of seven states was obtained on May 25. Through discussion and debate it became clear by mid-June that, rather than amend the existing Articles of Confederation, the convention would draft an entirely new framework for the government. All through the summer, the delegates debated, drafted, and redrafted the articles of the new Constitution in closed sessions. Among the chief points at issue were how much power to allow the central government, how many representatives in Congress to allow each state, and how these representatives should be elected--directly by the people or by the state legislators. The Constitution was the work of many minds and stands as a model of cooperative statesmanship and the art of compromise."@en, "Федеральное собрание собралось на заседание в Доме правительства (зал Независимости) 14 мая 1787 года для пересмотра Статей Конфедерации. Поскольку вначале на заседании присутствовали представители только двух штатов, Собрание было распущено на несколько дней до тех пор, пока 25 мая не был обеспечен кворум из представителей семи штатов. В ходе дискуссий и дебатов к середине июня стало понятно, что собрание было намерено скорее составить новый вариант структуры правительства, нежели чем пересматривать существующие Статьи Конфедерации. В течение всего лета делегаты обсуждали, составляли черновые варианты статей новой Конституции и тут же их пересматривали в ходе закрытых заседаний. Среди основных обсуждавшихся вопросов были вопросы степени власти и полномочий, которыми должно быть наделено центральное правительство, количества представителей в Конгрессе от каждого штата, а также процедуры переизбрания этих представителей — непосредственно жителями штатов или законодательными собраниями штатов. Конституция была плодом работы многих политиков и является ярким примером сотрудничества государственных деятелей и искусства компромисса."@ru, "اجتمع ممثلو الاتحاد الفدرالي في قصر الدولة (قاعة الاستقلال) في فيلادلفيا يوم ١٤  أيار ١٧٨٧ لتعديل النظام الأساسي للاتحاد. وحيث حضر وفدان اثنان فقط من وفود الولايات في البداية، رفع الأعضاء الحضور الجلسة من يوم إلى آخر حتى اكتمل النصاب القانوني بحضور وفود سبع ولايات في ٢٥ أيار. وقد اتضح خلال المناقشات والحوار بحلول منتصف حزيران أنه بدلا من تعديل مواد الاتحاد الكونفدرالي القائمة، كان على المؤتمرين صياغة إطار جديد تماما بالنسبة للحكومة. وطوال ذلك الصيف، ناقش المندوبون وصاغوا ثم أعادوا صياغة مواد الدستور الجديد في جلسات مغلقة. ومن بين النقاط الرئيسية التي دار حولها الجدل مدى صلاحيات الحكومة المركزية وعدد الممثلين في الكونغرس لكل ولاية ، وكيفية انتخاب هؤلاء ممثلين -- بالانتخاب المباشر من الشعب أو من قبل مشرّعي الولايات. لقد كان الدستور من عمل عقول كثيرة وهو يمثل نموذجا لفن الحكم التعاوني حنكة التوصل إلى الحلول الوسط."@ar ;
    dcterms:identifier "http://localhost/item/2708/about.rdf#item" ;
    dcterms:language <http://www.lingvoj.org/lang/en> ;
    dcterms:publisher <http://dbpedia.org/resource/National_Archives_and_Records_Administration> ;
    dcterms:spatial <http://dbpedia.org/resource/North_America>, <http://dbpedia.org/resource/United_States_of_America>, "América del Norte"@es, "América do Norte"@pt, "Amérique du Nord"@fr, "Estados Unidos da América"@pt, "Estados Unidos de América"@es, "North America"@en, "United States of America"@en, "États-Unis d'Amérique"@fr, "Северная Америка"@ru, "Соединенные Штаты Америки"@ru, "أمريكا الشمالية"@ar, "الولايات المتحدة الأمريكية"@ar, "北美"@zh, "美国"@zh ;
    dcterms:subject <http://dbpedia.org/resource/Constitutions> ;
    dcterms:temporal "1700 AD - 1799 AD"@en, "1700 ap. J.-C. - 1799 ap. J.-C."@fr, "1700 d.C. - 1799 d.C."@es, "1700 d.C. - 1799 d.C."@pt, "1700 н.э. - 1799 н.э."@ru, "1700 公元 - 1799 公元"@zh, "١٧٠٠ م - ١٧٩٩ م"@ar ;
    dcterms:title <http://dbpedia.org/resource/Constitution_of_the_United_States> ;
    ore:aggregates <http://localhost/static/c/2708/reference/00303_2003_004_pr_thumb_item.gif>, <http://localhost/static/c/2708/service/00303_2003_001_pr.jpg>, <http://localhost/static/c/2708/service/00303_2003_002_pr.jpg>, <http://localhost/static/c/2708/service/00303_2003_003_pr.jpg>, <http://localhost/static/c/2708/service/00303_2003_004_pr.jpg> ;
    ore:isDescribedBy <http://localhost/item/2708/about.rdf> ;
    a <http://purl.org/ontology/bibo/Manuscript> ;
    rdfs:seeAlso <http://hdl.loc.gov/loc.wdl/dna.2708> .

Notes

1. Sadly, the URIs are uglyish due to some constraints from our caching configuration. I figure we can redirect uglyish URIs to cool ones and make use of owl:sameAs if those constraints go away.
2. sans certain low-quality derivatives such as small thumbnails and tiles for the zoom interface
3. I was poking through the DBpedia output for Geonames URIs as well, but my method was way too slow and clunky, so that's disabled for the time being. Clients can always follow their noses from the DBpedia output.

I've been periodically poking at getting Linked Data/RDF views hooked into the World Digital Library web application, following Ed Summers' lead from his work on Chronicling America. The RDF views also use the OAI-ORE vocabulary to express aggregations — in WDL, an item is an aggregation of its constituent files. The goal is to provide a semantically rich and holistic representation of a WDL item (identifier, constituent files, metadata, translations, and so on).

The ORE format is a new one for me so it's hard to say whether the output of my dev branch is valid ORE or not. Plus I'm a sucker for validators. Turns out Rob Sanderson has developed a Python library for validating ORE, and this little snippet is what I've been using to validate the ORE. I didn't put much effort into making it readable, so much as banging something functional out so I can meet deadlines, so mea culpa and all that. But without further hemming and hawing, the code:

# validate.py
import sys
from foresite import *
 
rem = RdfLibParser().parse(ReMDocument(sys.argv[1]))
aggr = rem.aggregation
n3 = RdfLibSerializer('n3')
rem2 = aggr.register_serialization(n3)
print rem2.get_serialization(n3).data

Most of this code is naively copied and pasted from Rob's excellent Foresite documentation.

I invoke it thusly: python validate.py {URL}

And the output:

@prefix _27: <http://www.semanticdesktop.org/ontologies/nfo#>.
@prefix _28: <http://localhost/en/item/1/id#>.
@prefix _29: <http://localhost/en/item/1/>.
@prefix bibo: <http://purl.org/ontology/bibo/>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ore: <http://www.openarchives.org/ore/terms/>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix rdfs1: <http://www.w3.org/2001/01/rdf-schema#>.
 
 _28:ResourceMap a ore:ResourceMap;
     dc:format "text/rdf+n3";
     dcterms:created "2009-07-31T14:23:31Z";
     dcterms:modified "2009-07-31T14:23:31Z";
     ore:describes _29:id. 
 
 _29:id a bibo:Image,
         ore:Aggregation;
     dcterms:DDC "973";
     dcterms:alternative "Antietam, Maryland. Allan Pinkerton, President Lincoln, and Major General John A. McClernand"@en;
     dcterms:created "1862年10月3日"@zh,
         "3 de octubre de 1862"@es,
         "3 de outubro de 1862"@pt,
         "3 octobre 1862"@fr,
         "3 октября 1862 года"@ru,
         "October 3, 1862"@en,
         " ٣ آكتوبر، ١٨٦٢"@ar;
     dcterms:creator "Gardner, Alexander"@en,
         "Gardner, Alexander"@es,
         "Gardner, Alexander"@fr,
         "Gardner, Alexander"@pt,
         "Гарднер, Александр"@ru,
         "جاردنر, أليكسندر"@ar,
         "加德纳, 亚历山大"@zh;
... (and so on and so forth)
     dcterms:title "Antietam, Maryland. Allan Pinkerton, President Lincoln, and Major General John A. McClernand: Another View"@en,
         "Antietam, Maryland. Allan Pinkerton, el Presidente Lincoln y el General Principal John A. McClernand: Otra visión"@es,
         "Antietam, Maryland. Allan Pinkerton, le président Lincoln et le général-major John A. McClernand: Autre vue"@fr,
         "Antietam, Maryland. Allan Pinkerton,  Presidente Lincoln e Major-General John A. McClernand: Outra Vista"@pt,
         "Антитэм, штат Мэриленд. Аллан Пинкертон, президент Линкольн и генерал-майор Джон А. Макклернанд: Другой снимок"@ru,
         "أنتينام، ميريلاند ألان بينكرتون، الرئيس لينكولن، واللواء جون أ. ماكليرناند: منظر آخر"@ar,
         "安蒂特姆，马里兰州 艾伦·平克顿、林肯总统和少将约翰·A ·马克克拉南: 另一个视角"@zh;
     ore:aggregates <http://localhost/static/c/1/reference/04326u_thumb_item.gif>,
         <http://localhost/static/c/1/service/04326u.tif>;
     ore:isDescribedBy <http://localhost/en/item/1/item.rdf>;
     rdfs:seeAlso <http://hdl.loc.gov/loc.wdl/dlc.1>. 
 
 <http://localhost/static/c/1/reference/04326u_thumb_item.gif> a _27:FileDataObject;
     dcterms:format "image/gif";
     _27:fileSize "34531"^^<http://www.w3.org/2001/XMLSchema#long>. 
 
 <http://localhost/static/c/1/service/04326u.tif> a _27:FileDataObject;
     dcterms:format "image/tiff";
     _27:fileSize "1301614"^^<http://www.w3.org/2001/XMLSchema#long>. 
 
 ore:Aggregation rdfs1:isDefinedBy <http://www.openarchives.org/ore/terms/>;
     rdfs1:label "Aggregation". 
 
 ore:ResourceMap rdfs1:isDefinedBy <http://www.openarchives.org/ore/terms/>;
     rdfs1:label "ResourceMap".

You might pick up on some warts I have yet to fix, but there you go.

[Series]

In the prior I2 post, I wrote about the requirements the repositories subgroup has come up with for an institutional identifier standard (with the hope that our findings re: repositories could be generalized to other scenarios).

My strawman proposal of sorts is to explore how well linked data patterns fit this problem space. Linked data, briefly, is a way to expose and link data on the web in a more semantically meaningful way, and is often summarized using the four principles put forward by Tim Berners-Lee:

1. Use URIs as names for things
2. Use HTTP URIs so that people can look up those names.
3. When someone looks up a URI, provide useful information.
4. Include links to other URIs. so that they can discover more things.

That's the crux of it.  Linked data takes well-known patterns on the web (linking, dereferencing, etc.) and applies them to data, which in this case could be metadata for identifying institutions.

Let's examine each of the requirements and the applicability of linked data thereto.

1. Should be agnostic to type of institution, e.g., libraries, museums, personal collections, historical societies: The web is already agnostic to type of institution.  HTTP URIs do not favor one type of institution over another.
   
2. Should handle varying institutional granularity, e.g., institution-level, campus-level, division-level, unit-level: HTTP URIs are flexible in this regard.  Hierarchy, should one wish it to be surfaced in the identifier, may be encoded in either a DNS hostname or the path appended to the DNS name.  One can imagine a URI like "http://department.division.institution.tld/unit/subunit" or "http://institution.tld/campus/office/individual".
   
   Hierarchy needn't be surfaced in the identifier if one favors opacity, in which case "http://registry.tld/xnjsdasd" would suffice as an identifier, and may instead be entirely reflected in the (RDF) representation returned by dereferencing the URI.
   
3. Should handle linking among institutions and subordinate units: Linked data handles linking via well-known HTTP mechanisms, referenced in the fourth principle of linked data.  Unlike the HTTP link, which has limited semantics, linked data links are semantically rich and extensible.
   
4. Should express different sorts of relationships among these institutions and units: The "useful information" in the third principle of linked data is typically provided by an RDF representation, which is itself a list of assertions.  These assertions, or triples, consist of subjects, predicates, and objects.  The ability to express the relationships in this requirement is limited only by the availability of vocabularies that contain sets of predicates and classes for subjects and objects.  Think of the predicates as elements defined within a metadata standard, e.g., Dublin Core "creator", MODS "relatedItem", and so forth.  Vocabularies that contain these predicates and classes are growing and evolving daily, and should there not be a vocabulary that contains the relationship one wishes to express, it is fairly easy to create a custom vocabulary.
   
   The ability to mix and match vocabularies provides an expressiveness that is often not found in document-based metadata formats and the flexibility to express radically different relationships on a per-industry or per-institution basis.  This latter point is important as the I2 group has identified both core metadata elements for identifying institutions of different types and additional elements for specific types of institutions.  Why re-invent a new metadata format or schema when all one needs to express may already be contained in others?
   
5. Should relate to existing relevant identifiers and registries: Same as requirement#4.  Linked data is all about expressing relationships between things, e.g., institutions, identifiers, registries, etc.
   
6. Should be globally unique: HTTP URIs are guaranteed to be globally unique by virtue of the distributed DNS system and hierarchical naming within each HTTP service.
   
7. Should be actionable: HTTP URIs provide dereferenceability/actionability via the well-known HTTP protocol.
   
8. Should enable retrieval of metadata sufficient to identify the institution, which may vary widely by institution: HTTP URIs are actionable per requirement #7 and the metadata returned is flexible per requirement #4.
   
9. Should accommodate changes as institutions come and go and re-organize and be able to relate defunct institutions to new ones: Linked data patterns provide for redirecting from defunct representations (institutional identifiers) to new ones via HTTP redirects.  One may also add assertions to institutional metadata such as owl:sameAs, for instance, which says that the institution identified by the given URI is the same as another institution identified by another URI.
   

This seems like a compelling path to follow for the I2 standard.

The I2 repositories subgroup will be sending out its survey on identifier use cases in the coming week.  It will be interesting to see if the requirements we have thus far identified still obtain in light of the data we collect from the survey.  If so, I would like to explore the idea of linked data for institutional identifiers a bit more.

Lack of Talent, its hour come round at last, slouches towards podcastdom to be born.

It's late and I'm tired, so here's the skinny: at the beginning of the year I ambitiously[1] resolved to record one song per month. Instead I've serendipitously turned up the LOT recording sessions from July 2005, which we call the Burlap Overseas, and which I never really went through. Now that stuff is backed up six ways from Sunday[2] and I owe it to my fellow Lack of Talenteers to go through all these hours of raw audio and pick out some interesting bits so we have something to build on the next time we get together[3].

If you're interested, feel free to subscribe to the podcast and listen along. Updates will be sporadic, perhaps even spasmodic or spastic. Now the disclaimers: you should know that LOT was never about songs or practice or technique or order or music, really; we are true to our name[4]; it's about some friends gathering in my grandparents' basement with lots of music gear[5], even more alcohol, a box fan to keep us cool, a washing machine to clean Gramma's clothes, and a microphone that runs the whole darned time. This is booze-soaked sonic experimentation among close friends and even if you hear nothing else, you should hear hints (or squeals, or yawps) of joy amidst the cacophony.

Notes

1. Read: foolishly
2. Phew. I am a paranoid backup freak.
3. Est. 2013
4. At least I am
5. We switched instruments often, sometimes even playing the ones we could "play."

I finally pushed out some embarrassingly outdated WordPress plugin updates a few moments ago.

• Updated unAPI plugin with a patch contributed by Jay Luker that removes the hard-coded "wp_" table prefix. The updated version of the plugin has been tagged as 1.4.1.
• Updated LinkPURL plugin with a patch contributed by Mark Matienzo that enables partial redirects. I made some additional tweaks to the plugin to make this feature configurable via the WordPress management UI. This has been tagged as 1.1.
• Created a new unAPI plugin branch for Mark Matienzo's Scriblio-oriented tweaks. The branch is called 1.4.1-anarchivist-scriblio and it contains the scriblio.diff file. I have yet to integrate the diffs, as the file that was patched has changed since the patch was issued. If anyone is interested in working on unAPI/Scriblio integration, please get in touch with me.

And here is my to-do list which I hope will keep me honest.

• Update OAI-ORE plugin to support version 1.0 of the ORE specification.
• Add per-post (and per-page?) resource maps that wrap all embedded images and links.
• Enable "cool URIs" for all resource maps.

It is my hope that I'll get to those sometime before the summer begins. :)

On Monday I woke up with a very mild and very annoying bronchial infection. Doctor Me prescribed two days of rest, relaxation, and chicken soup. Where "chicken soup" is "finally dropping the unreasonably expensive and embarrassingly outdated web hosting package at Speakeasy and transferring all of my domains and content to Dreamhost," that is. I am now paying less than a third of what I had been for a hell of a lot more features. And, I must say, administering DNS records, transferring files, and upgrading long-neglected software is rather amusing when you're loopy and feverish.

My experiences thus far with Dreamhost are very promising. I'm impressed but perhaps that's because I've been in the web hosting ghetto for so long. I understand there will very likely be downtime and sluggishness — that I can deal with. Being shackled to 1999 technologies for $30/mth, while my e-mails go unanswered, not so much.

I upgraded both Technosophia and my wife's blog to the latest WordPress release (2.3) from something ridiculous like 2.0.3. In doing so, I also switched to the svn upgrade configuration Ryan Eby detailed a while back.

I crossed my fingers and it turns out the unAPI server plug-in still works in WP2.3. Huzzah! Not sure if it works in the 2.1 or 2.2 branches, but I suspect it does.

I proposed an NJ Library BarCamp some months ago, not realizing that efforts were already under way to do the same in NYC. In retrospect, I'm glad I didn't do anything to get things moving; I wouldn't have pulled things together nearly as well as the NYC folks did. The event was excellent. It was my first camp, and I'd definitely try another. A big thanks to Stephen Francoeur et al.

Here are the three sessions I attended, with links to the "official" wiki pages for summaries:

• Solr and Lucene (session moderated by AIP's Mark Matienzo and NYU's Jason Casden) seem to be gaining momentum in the library world. Having gone to the last Code4Lib conference, my head was already chock full of relevant tidbits, but the moderators did a great job of showing examples, evangelizing, and keeping the discussion going.
• Grid Services (session moderated by OCLC Openly Informatics' Eric Hellman) might have been very interesting if I hadn't kept receiving phone calls from an insurance company. I had to take the calls, and so this session was difficult to follow. The basic idea was to think of networked library services like the power grid. What would libraries want from the grid? What would they be willing to contribute back?
• Semantic Web (session moderated by NYU's Corey Harper and CUNY's Sunny Yoon) was the most widely attended session I went to: standing room only! When I first added the topic to the wiki, I had no idea it would draw this many people. Odd that I would suggest this topic since I had little to offer on the topic, so I gleaned an awful lot. The discussion was spirited and, as you might expect, the RDF vs. microformats arguments flew fast and furious across the room. I'm left wondering if the RDFa/GRRDL approach might not be a good middle-road between the "everything must be represented as RDF in a triplestore" camp and the "just embed microformats in xhtml" people.

And now, the requisite name-dropping. I got to reconnect with a bunch of people I hadn't seen in a while, like Terry Catapano, Jay Datema, Nicole Engard, Valerie Forrestal, Kevin Reiss, and Sunny Yoon. And I got to meet LibLime's Chris Cormack, NYPL's Josh Greenberg, Corey Harper, Mark Matienzo, Jenkins Law's RayAna Min Park, and Steven's Tech's Linda Scanlon, among other people.

It was about as good as any camp without kayaks and archery can be. Check out some more summaries.

This is a slightly modified (read: rough) transcription of the talk I gave at this year's NJLA conference, called "Library Revolution."

The abstract described an idealistic scenario:

Imagine, if you will, a world where library services are automatically discovered; Library users retrieve information objects and metadata with a single click, never having to navigate the dark alleys of dead-ends that are full-text resolvers; Information sources and services are connected and remixed according to user preferences and needs, where and when they wish. What if we could leverage existing library and industry standards, applications, and protocols to make this a reality? And soon?

In this scenario, a potential library revolution could be fomented — in which the goal would be to return the means of production to users, to hand over the reins, to re-envision ourselves as tool- and service-building artisans, as Karen G. Schneider described in her keynote at the Code4Lib 2007 conference, rather than gatekeepers and information proxies — and I'm going to suggest some ways this might be achieved. For now I'll assume it's self-evident why it is desirable to, generally speaking, get "our stuff" "out there" and meet users at their points of need.

Rather than get into nitty-gritty details, I'd like to describe a higher-level vision which has been put forward by a host of library technologists that have come before me (especially Daniel Chudnov). Some aspects of my vision may indeed be pie-in-the-sky, but consider this:

1. Isn't pie delicious?
2. Shouldn't we reach for it?

So, what's the problem? Why a revolution? Here are some (arguably trite) observations:

1. Full-text resolvers do not work well. You should not have to click through two, three, or four windows to get at full-text — assuming it's actually there and not a complete dead end! Don't get me wrong — it's better to have access to full-text through a resolver than not to. I'd like to see more resolver systems that implement look-ahead resolution like Oregon State University's new, and freely available, metasearch tool, LibraryFind. LF uses what Jeremy Frumkin, the Chair of Innovative Library Services at OSU, likes to call "two-click workflow": one click to find, one click to get.
2. Information splatter. We've accumulated too many silos and need to figure out better ways to access all of that information via a single interface, whether the method is federation, aggregation, or something else. Users should not have to go to multiple sites to search our collections for resources of interest.
3. Sandboxing. Our content and services are, generally speaking, tightly coupled to our websites, so we are generally unable to meet users at their points of need.
4. Service usage — reference desk visits, OPAC searches — appears to be dwindling.
5. Growing popularity of Google, Amazon, and "web 2.0" or social networking sites — del.icio.us, flickr, twitter, myspace, facebook, ning, librarything. These sites are great — especially MySpace, where I get all sorts of offers for new prescription drugs and live adult webcams. But these sites really -are- great. They empower users to connect with one another, to describe their own resources, to share with others, to remix information. And most of all? They're incredibly easy to use. Are our tools as easy to use? Are we similarly empowering users?

An aside on "2.0": Although I cringe at the viral "2.0" meme — web 2.0, library 2.0, business 2.0, identity 2.0, enterprise 2.0, learning 2.0, travel 2.0… — it is interesting to note that there is something to "2.0". Something revolutionary. And it's not folksonomies, it's not tagging, it's not tag clouds, it's not sharing, it's not any particular site or idea. It is the very fabric of "2.0", and that is a re-envisioning of the web from connecting people with data to connecting people with people. The web has evolved from a network of interlinked documents to an extension of the social fabric connecting us all.

As you can see, a revolution of sorts has already begun. Time magazine selected "You" as their 2006 person of the year. When MSNBC covered the story, the headline read "From blogs to YouTube, user-generated content transforms the Internet". I'm personally not that interested in the social networking aspect, and it already receives a lot of coverage from the library 2.0 gang. Library 2.0 is a popular topic now, and much has been said of wikis, blogs, and RSS. These are important topics but others are already covering them quite well. The point to take away from 2.0, in my view, is that it's empowering and inspiring users to do things with information they previously were not able or willing to do. Ask tens of millions of people to help us catalog MARC records? Right. But ask them to tag videos on YouTube, bands on Last.FM, images on Flickr, links on del.icio.us, and so forth? There you go. My areas of interest with regard to library revolution are unifying our content and services, getting them outside the library sandbox, and returning the means of production in this very "2.0" way.

Let's step through some technologies and technological concepts that may play a role in reaching this outcome.

• Systems integration: We have accumulated a wealth of resources over the years and have purchased, or built, or licensed, numerous systems to access these resources that have traditionally been disparate. This is a great accomplishment; the more information we can get into the hands of our users, the better. The process doesn't scale, though, and has resulted in a proliferation of information silos. Because of thorny issues of interoperability, not to mention licensing issues, technological incompatibilities, and lack of resources, we have thus far struggled to bridge the gaps between these silos. The result? A number of different search interfaces, with different result sets, in different formats, supporting different depths of coverage.
   
   How can we reconcile in our users' minds this information environment with the "simple, single search box" mentality of the Google age? What if we built bridges between our systems? Pull together metasearch with the link resolver, the link resolver with the catalog, the catalog with institutional repositories. Easy, right? Well, no. But at the very least, if you can get XML out of these systems — whether through OAI-PMH, or SRU, or a database export — you can bring it together. Index it with a tool like Solr, and you've got your Google-ish library search tool.
• Auto-discovery: Auto-discovery is used by a number of technologies, though perhaps its usage to announce syndication (RSS) feeds is the most well-known. The mechanism for syndication auto-discovery is actually quite simple. Got a feed for your site? Add a single line of HTML code to any page you'd like to announce it on, and modern web browsers will pick it up and clue you in.
   
   In HTML, there is a LINK tag, not to be confused with the A tag (which stands for anchor) commonly used for hyperlinks. The anchor and link tags differ in the following ways:
  • Anchor tags may have text content and show up as labels for links. For instance, you might link to FoxNews.com and label it "Fair and balanced? Yeah right." LINK tags do not have text content.
  • Actionability: Anchor tags are clickable. They take you someplace. LINK tags are not clickable.
  • Context: Anchor tags appear in the body of a document. LINK tags appear in the HEAD.
  • Semantics: Anchor tags may represent any number of things. It might be a link to content further down in the current page, it might link to another page entirely, or it might even be used to activate some javascript or launch a popup window. LINK tags are used solely to describe document relationships, more semantic information. For instance, a LINK tag might describe a link to the next and previous chapters in an e-book, a LINK tag might be used to link to alternative representations of a document, such as versions in other languages, or versions formatted in RSS or the Atom syndication format. The LINK tag is a great way to leverage the existing web architecture to handle the problem of "one resource, many representations", and I wouldn't be surprised if the OAI-Object Reuse and Exchange initiative took a hard look at it.

  The LINK tag sort of auto-discovery, such as for syndication feeds, is common, but is not the only implementation of auto-discovery. There are more sophisticated ways, such as Zero Configuration Networking.

• Syndication: You've probably heard a lot about RSS, or Really Simple Syndication, and I wouldn't be surprised if most of you are already using it. It's a great technology, simple to use and implement, and I know it saves me a great deal of time on a daily basis. Instead of having to click through and browse the 50 or so websites I track regularly, I read updated content from each site in my feed aggregator in a unified interface. A lot of attention is already paid to RSS, especially in library 2.0 circles, so I won't say much more about it. Syndication allows content to be syndicated into feeds that folks can subscribe to and unsubscribe from willy-nilly.
   
   But I thought it was important to include an explicit mention of syndication since a couple of the other topics relate to it, and since it is a great example of getting stuff out there. Rather than requiring your audience to come to your website, syndication enables them to read your content in an environment of their choosing. It's worth noting that my wife is not a fan of syndication. She likes the experience of going to different websites, enjoying their different takes on web design, and compartmentalizing her web surfing. And that's great; no one, to the best of my knowledge, has advocated an "RSS-only" interface. Content available in the RSS format is also available otherwise, so it is a convenient option for people like myself.
   
   One more point about RSS, despite saying I wouldn't talk much about it. It's kind of an academic point, but I feel it warrants some clarification. The term RSS has quickly become the Band-Aid, or the Kleenex, of syndication feeds. RSS is one of a number of formats used for marking up syndication feeds. Another is the Atom Syndication Format. Most browser and feed aggregators are fully aware of both feed types — for instance, Bloglines has supported both formats since June of 2006 — and they generally should render the same, and that's why you don't hear about Atom much; it's a detail that is, for the most part, behind the scenes.
• OpenSearch: Does anyone here have a website or a catalog? Do they have search interfaces? Perfect, you're about a third of the way there. OpenSearch is a specification for some simple formats that allow you to share search results. Just as syndication allows you to decouple your content from your website, OpenSearch allows you to decouple your search engines from your websites. Here's how it works:
  1. Go to your search page and look at the URL after you run a search
  2. Write an OpenSearch description document
  3. Embed a LINK tag linking to the OpenSearch description document, for auto-discovery
  4. Return search results in RSS or Atom

  You might ask "why bother?" Firstly, the newest browsers — FF2 and IE7, among others — support auto-discovery of OpenSearch targets. So folks can search Google, Wikipedia, Amazon, eBay … and your websites or catalogs directly from their browser. Secondly, it allows for fairly simple federation of searches across OpenSearch targets. Since each target contains a description document that is machine-readable, I can point my OpenSearch client at a number of targets, find their descriptions, and learn how to search them. Results are, by convention, returned in RSS or Atom, which are easily crosswalkable, so aggregating result sets is fairly trivial (though how to sort or rank them is tricky). Thirdly, since results are returned as RSS or Atom, one can in effect subscribe to search results. For example, you could subscribe to a search on Wikipedia for "Anarcho-Syndicalism", and your feed aggregator will be alerted whenever that search returns new results. Or, a Linguistics professor could subscribe to your catalog's OpenSearch target, hoping to be alerted when new materials about Germanic syntax are cataloged — and it's worth noting, this is as easy as just two or three clicks in a web browser.

• unAPI: Numerous tools and protocols exist for integrating library resources into other information systems, library or otherwise. OAI-PMH and OpenURL are two great examples of successful and widely deployed technologies. Unfortunately, few developers outside the relatively small world of library technology know anything about library standards, and this is seen as a significant integration barrier. Dan Chudnov, a librarian programmer at LC, reflected on this: 'we librarians and those of us librarians who write standards tend, in writing our standards, to "make complex things possible, and make simple things complex."'
   
   To address this issue, a number of librarians and technologists came together to develop a new standard called unAPI. unAPI is a tiny web-based specification designed to solve the problem of identifying, copying, and pasting discrete content objects to and from web applications (including catalogs, bibliographic databases, repositories, link resolvers, and so forth), making it simpler for developers outside the library world to get at our vast intellectual resources. The objective of unAPI, then, is to enable web sites with HTML interfaces to information-rich objects to simultaneously publish richly structured metadata for those objects, or those objects themselves, in a predictable and consistent way for machine processing.
   
   unAPI consists of three parts: A microformat for embedding object identifiers in HTML, an HTML LINK tag for unAPI service auto-discovery (as used for RSS, Atom, and OpenSearch), and a web service consisting of three functions–get formats , get formats for x identifier , get format y of identifier x — two of which have a standardized response format, returning XML.
• ZeroConf: I want to acknowledge Dan Chudnov again, for suggesting that Zero Configuration Networking might have a place in library services. The general question here is "why can't library tools be as cool as iTunes is?" Just waltz into Starbucks, connect to the wi-fi, and you can see everyone else's playlist. You can listen to their music, even. What sort of magic made this sort of auto-discovery "just work?"
   
   The technology is called Zero Configuration Networking, or ZeroConf, though you may see older mentions under the names Rendezvous and Bonjour. Without getting into the hairy details, ZeroConf is a small stack of fairly low-level technologies that piggy-back on the ubiquitous domain name system (or DNS), which enables us to type identifiers like "google.com" and "nytimes.com" into a web browser and rest assured that our computers will take care of the rest for us — looking up the domain name, finding the network address of the server, connecting to the server on an appropriate port, and so forth. ZeroConf allows machines to connect to networks without any knowledge of what's already on the network, without regard for the type of network topology or infrastructure, and both register the services it provides and query the services already provided by other nodes on the network. It sounds complicated, but everytime you walk into Starbucks and start up iTunes, it seems pretty trivial. It "just works."
   
   Wouldn't it be great if users could discover our services and resources that easily? What if we went through with systems integration and announced that unified service via ZeroConf? A visiting scholar could enter our library, connect her machine to the network — and let's forget about authentication and authorization for now — and immediately find our new service, from which she could run a simple search against all of our bibliographic databases, all of our catalog records, all of our full-text holdings, and all of our repository objects. What if library services "just worked"?Significant work needs to be done in this area before it becomes viable as I've just described, but I find it to be a compelling vision.

The technology as is widely acknowledged is the easy part. So how do we get there? How do we re-envision ourselves as library artisans? How do we craft services that "just work?" How can we investigate all these technologies that let us unleash our considerable assets?

1. Commitment to innovation. If you can afford to have skunkworks in your organization, even if it's only one employee, or allowing a couple of creative individuals to devote 10% of their time to innovative pursuits, it's worth it.
2. Bold direction.
3. Think outside the orgchart — leverage collaborative development, forge communities, make the most of your consortial ties.
4. … You tell me.

We can yield revolutionary results via small steps and a bold, forward-thinking direction. Pie in the sky? Maybe, but isn't pie delicious? (Yes, that was a glib and abrupt ending, but I'm tired of editing.)