RE: Library of Congress Subject Headings as SKOS Linked Data

Richard,

>(I'm ignoring the availability of RDFa in my argument -- 
>unfortunately there is no way for a client to indicate that it supports
RDFa AFAIK,  
>so it cannot really be factored into the content negotiation equation.)

As you may guess I have a comment regarding this one ;) 

I'm note sure if I understand this correctly ('no way for a client to
indicate that it supports RDFa') but, though RDFa uses
'application/xhtml+xml' MIME type, there are several ways to
declare/detect RDFa content. All my statements are based on the latest
RDFa syntax CR document at [1].

First (not preferred by some people ;) you could/should use the type
declaration (<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">). Further, people are
encouraged to use the according @profile (<head
profile="http://www.w3.org/1999/xhtml/vocab">) and/or the version
attribute (<html xmlns="http://www.w3.org/1999/xhtml"
version="XHTML+RDFa 1.0" ... />).

Finally, the W3C TAG also addresses this issue, see [2].

Please feel free to discuss this issues also at our RDFa community Wiki
(e.g. at [3]).

Cheers,
	Michael

[1] http://www.w3.org/MarkUp/2008/CR-rdfa-syntax-20080612/#s_conformance
[2]
http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html#UsingRDFa
[3] http://rdfa.info/wiki/Tutorials#Good_practice

----------------------------------------------------------
 Michael Hausenblas, MSc.
 Institute of Information Systems & Information Management
 JOANNEUM RESEARCH Forschungsgesellschaft mbH
  
 http://www.joanneum.at/iis/
----------------------------------------------------------
 

>-----Original Message-----
>From: public-swd-wg-request@w3.org 
>[mailto:public-swd-wg-request@w3.org] On Behalf Of Richard Cyganiak
>Sent: Wednesday, June 11, 2008 1:18 AM
>To: Ed Summers
>Cc: SWD Working SWD; public-lod@w3.org
>Subject: Re: Library of Congress Subject Headings as SKOS Linked Data
>
>
>Ed,
>
>A very cool service, and exemplary attention to detail!
>
>Of course, I still have a few suggestions! I haven't read through the  
>entire thread, so apologies if some of this was mentioned already.
>
>(I saw 303s being mentioned in the thread -- you are doing things the  
>right way, there's no need to do 303s at <sh95000541>. It is an  
>information resource and therefore 200 is fine. The concept is  
><sh95000541#concept>, a URI that cannot be directly dereferenced via  
>HTTP, so you are consistent with httpRange-14, as explained in the  
>Cool URIs document. This is one of the nice things about hash URIs.)
>
>1. The content-negotiated URI should send a "Vary: Accept" header.  
>This helps caches to deal correctly with content-negotiated resources.
>
>2. The correct MIME type for N3 is "text/rdf+n3;charset=utf-8", not  
>"text/n3". (I think the spec used to recommend text/n3, but has been  
>changed some time ago.)
>
>3. I would suggest adding a few triples to the RDF/XML and N3  
>versions, to link the generic document to its variants, and the  
>generic document to the concept. Example (choose your own favourite  
>properties):
>
><sh95000541> foaf:primaryTopic <sh95000541#concept> .
><sh95000541> dcterms:format <sh95000541.rdf> .
><sh95000541> dcterms:format <sh95000541.n3> .
><sh95000541> dcterms:format <sh95000541.json> .
><sh95000541> dcterms:format <sh95000541.html> .
>
>This helps RDF browsers to relate all those resources.
>
>4. The content negotiation could benefit from a little bit of  
>tweaking. You correctly handle q values, which is great. It would be  
>even better if there was a slight bias towards the non-HTML 
>formats. I  
>would argue that the data variants are quite a bit more useful than  
>the HTML variant, as RDF-aware clients can do all sorts of cool stuff  
>with the RDF that are not possible . Therefore, a client that  
>indicates identical preference for HTML and RDF/XML should be served  
>RDF/XML. FWIW, Tabulator has a preference of 1.0 for XHTML and 
>0.8 for  
>RDF/XML. It would be great if your algorithm would return RDF/XML in  
>this case.
>
>(I'm ignoring the availability of RDFa in my argument -- 
>unfortunately there is no way for a client to indicate that it supports
RDFa AFAIK,  
>so it cannot really be factored into the content negotiation equation.)
>
>5. Ideally, you would add the skos:prefLabels of all related concepts  
>to the RDF output. This would support navigation in RDF browsers.
>
>Again, great work!
>
>Best,
>Richard
>
>
>On 9 Jun 2008, at 14:54, Ed Summers wrote:
>
>>
>> I'd like to announce an experimental linked-data, SKOS representation
>> of the Library of Congress Subject Headings (LCSH) [1] ... and also
>> ask for some help.
>>
>> The Library of Congress has been participating in the W3C 
>Semantic Web
>> Deployment Working Group, and has converted LCSH from the MARC21 data
>> format [2] to SKOS. LCSH is a controlled vocabulary used to index
>> materials that have been added to the collections at the Library of
>> Congress. It has been in active development since 1898, and was first
>> published in 1914 so that other libraries and bibliographic utilities
>> could use and adapt it. The lcsh.info service makes 266,857 subject
>> headings available as SKOS concepts, which amounts to 2,441,494
>> triples that are separately downloadable [3] (since there isn't a
>> SPARQL endpoint just yet).
>>
>> At the last SWDWG telecon some questions came up about the way
>> concepts are identified, and made available via HTTP. Since we're
>> hoping lcsh.info can serve as an implementation of SKOS for the W3C
>> recommendation process we want to make sure we do this 
>right. So I was
>> hoping interested members of the linked-data and SKOS communities
>> could take a look and make sure the implementation looks correct.
>>
>> Each concept is identified with a URI like:
>>
>> http://lcsh.info/sh95000541#concept
>>
>> When responding to requests for concept URIs, the server content
>> negotiates to determine which representation of the concept 
>to return:
>>
>> - application/xhtml+xml
>> - application/json
>> - text/n3
>> - application/rdf+xml
>>
>> This is basically the pattern that Cool URIs for the Semantic Web
>> discusses as the Hash URI with Content Negotiation [4]. An additional
>> point that is worth mentioning is that the XHTML representation
>> includes RDFa, that also describes the concept.
>>
>> At the moment the LCSH/SKOS data is only linked to itself, through
>> assertions that involve skos:broader, skos:narrower, and 
>skos:related.
>> But the hope is that minting URIs for LCSH will allow it to be mapped
>> and/or linked to concepts in other vocabularies: dbpedia, geonames,
>> etc.
>>
>> Any feedback, criticisms, ideas are welcome either on either the
>> public-lod [5] or public-swd-wg [6] discussion lists.
>>
>> Thanks for reading this far!
>> //Ed
>>
>> [1] http://lcsh.info
>> [2] http://www.loc.gov/marc/
>> [3] http://lcsh.info/static/lcsh.nt
>> [4] http://www.w3.org/TR/cooluris/#hashuri
>> [5] http://lists.w3.org/Archives/Public/public-lod/
>> [6] http://lists.w3.org/Archives/Public/public-swd-wg/
>>
>
>
>

Received on Wednesday, 11 June 2008 07:29:52 UTC