"While these URL patterns would be useful, they would be even more useful
if they could be reached via the standard Linked Data mechanism of
quoting the base URL and specifying a content type in the Accept header.
This would imply the need to define MADS/RDF and SKOS as "official" HTTP
response content types."
-- Yes, this specific idea was bundled in the phrase "There are a few ways this could be done, but ....". There will be content-negotiated access (as there is now).
Warmly,
Kevin
________________________________________
From: Authorities and Vocabularies Service Discussion List [[log in to unmask]] On Behalf Of Richard Light [[log in to unmask]]
Sent: Tuesday, March 29, 2011 10:26
To: [log in to unmask]
Subject: Re: [ID.LOC.GOV] Announcement: MADS/RDF - Final Public Review
In message
<[log in to unmask]>,
"Ford, Kevin" <[log in to unmask]> writes
>Dear Richard,
>
>Thanks for your interest. We're still working out theses details, but
>I'm happy to share with the caveat that everything following is
>provisional. Naturally, comments are welcome.
>
>In short, there's no conflict. Both SKOS and MADS/RDF can be provided
>from the same URL. In no small part, this is because MADS/RDF has been
>fully mapped to SKOS. Therefore, if we only served the MADS/RDF, you
>would be able to infer the SKOS. We don't have plans to make anyone go
>through that kind of trouble; the current idea is to serve both SKOS
>and MADS/RDF simultaneously, from the same URL.
That would be good. However, in that case, presumably you would want to
simply lose the distinction between
http://id.loc.gov/authorities/sh85090955
and
http://id.loc.gov/authorities/sh85090955#concept
as distinct concepts, and the concomitant need for an owl:sameAs
relationship between them? All the assertions (MADS/RDF and SKOS) are
about the same concept, after all.
However, I guess you'll be sticking with the pattern that identifiers
all have the '#concept' suffix, since everything is already published
under that pattern of URL? I ask because the '#concept' in your URLs
breaks my "request forwarder" program - however that's clearly an issue
for me to address. And LoC won't be the only ones using "hash" URLs.
Come to think of it, I've done it myself:
http://light.demon.co.uk/shic.rdf#1.0 ;-)
although that's a rather different case, where the entire classification
is delivered by a single HTTP request.
>I also hope to offer optional "format" choices. If you only wanted the
>SKOS, you could request only the SKOS. Ditto for MADS/RDF. There are a
>few ways this could be done, but URL patterns will likely play a
>leading role. To break this down a little, and furnish you with a few
>examples:
>
>http://id.loc.gov/authorities/sh85090955.rdf - Requests MADS/RDF and
>SKOS for the Resource
>http://id.loc.gov/authorities/sh85090955.madsrdf.rdf - Requests *only*
>MADS/RDF for the Resource
>http://id.loc.gov/authorities/sh85090955.skos.rdf - Requests *only*
>SKOS for the Resource
While these URL patterns would be useful, they would be even more useful
if they could be reached via the standard Linked Data mechanism of
quoting the base URL and specifying a content type in the Accept header.
This would imply the need to define MADS/RDF and SKOS as "official" HTTP
response content types.
Richard
>________________________________________
>From: Authorities and Vocabularies Service Discussion List
>[[email protected]] On Behalf Of Richard Light
>[[log in to unmask]]
>Sent: Tuesday, March 29, 2011 08:54
>To: [log in to unmask]
>Subject: Re: [ID.LOC.GOV] Announcement: MADS/RDF - Final Public Review
>
>In message
><[log in to unmask]>,
>"Ford, Kevin" <[log in to unmask]> writes
>>Announcement: MADS/RDF - Final Public Review
>>
>>We look forward to your thoughtful reviews of this revised version of
>>the ontology by April 8. We encourage community feedback, as it is
>>important to the process and feel fortunate to work with such an
>>engaged group of professionals. Many of the changes, in fact, are the
>>result of community feedback, for which we're grateful. Thank you.
>
>Hi,
>
>This is not a comment on MADS/RDF itself (which looks good to my
>non-expert eye), but on how the examples suggest that LoC might
>implement it.
>
>To take Loch Ness as a case in point, the example MADS/RDF has this:
>
><rdf:RDF>
><madsrdf:Geographic
>rdf:about="http://id.loc.gov/authorities/sh85090955">
> <rdf:type rdf:resource="http://www.loc.gov/mads/rdf/v1#Authority"/>
> <madsrdf:authoritativeLabel xml:lang="en">Ness, Loch
>(Scotland)</madsrdf:authoritativeLabel>
> ...
><owl:sameAs
>rdf:resource="http://id.loc.gov/authorities/sh85090955#concept"/>
>
>I was intrigued by this owl:sameAs assertion, given that the URLs are
>identical apart from a fragment identifier (#concept). So I went
>looking for
>http://id.loc.gov/authorities/sh85090955#concept. The request:
>
>http://light.demon.co.uk/scripts/cgiforwarder.exe?url=http://id.loc.gov/a
>uthorities/sh85090955&accept=rdf
>
>which does the content negotiation game, does indeed give me the SKOS
>data for this concept:
>
><rdf:Description
>rdf:about="http://id.loc.gov/authorities/sh85074124#concept">
> <skos:prefLabel xml:lang="en">Lakes--Scotland</skos:prefLabel>
> </rdf:Description>
> ...
></rdf:RDF>
>
>But if the URL:
>
>http://id.loc.gov/authorities/sh85090955
>
>resolves to the SKOS description, how is one ever going to access the
>MADS/RDF description?
>
>Richard
>--
>Richard Light
>
>
>-----
>No virus found in this message.
>Checked by AVG - www.avg.com
>Version: 10.0.1204 / Virus Database: 1498/3536 - Release Date: 03/28/11
>
>
--
Richard Light
|