LISTSERV mailing list manager LISTSERV 16.0

Help for ID Archives


ID Archives

ID Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

ID Home

ID Home

ID  March 2011

ID March 2011

Subject:

Re: Announcement: MADS/RDF - Final Public Review

From:

"Ford, Kevin" <[log in to unmask]>

Reply-To:

Authorities and Vocabularies Service Discussion List <[log in to unmask]>

Date:

Tue, 29 Mar 2011 11:48:31 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (154 lines)

"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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

February 2024
January 2024
March 2023
January 2023
July 2022
June 2022
May 2022
April 2022
February 2022
November 2021
September 2021
August 2021
July 2021
June 2021
May 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
March 2020
February 2020
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
April 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2017
July 2016
February 2016
January 2016
December 2015
November 2015
September 2015
August 2015
June 2015
March 2015
February 2015
October 2014
August 2014
July 2014
June 2014
March 2014
January 2014
November 2013
September 2013
August 2013
June 2013
May 2013
April 2013
March 2013
December 2012
November 2012
October 2012
September 2012
August 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
April 2011
March 2011
February 2011
January 2011
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
November 2009
June 2009
May 2009

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager