Comments on: SKOS, Linked Data and LCSH! http://dynamicorange.com/2008/04/02/skos-linked-data-and-lcsh/?utm_source=rss&utm_medium=rss&utm_campaign=skos-linked-data-and-lcsh A low-frequency blog by Rob Styles Sun, 29 Apr 2012 07:29:20 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Ed Summers http://dynamicorange.com/2008/04/02/skos-linked-data-and-lcsh/#comment-1004 Ed Summers Wed, 23 Apr 2008 02:26:38 +0000 http://dynamicorange.com/wpblog/2008/04/02/skos-linked-data-and-lcsh/#comment-1004 hanks for the shout out. I did get around to taking Tom's suggestion to provide a lookup technique that preserves the URI for concepts. So instead of: http://lcsh.info/label/Beer followed by a redirect there is now a solr powered search http://lcsh.info/search?q=Beer Someday there will prolly be a SPARQL endpoint, but not just yet I don't think. I'd actually like to see what the data looks like in a Talis store :-) You ought to be able to use content negotiation to fetch application/rdf+xml and application/json for search results if you want. The HTML results are actually RDFa. Also, I've switched over to using hash URIs instead of slash URIs for identifying concepts. So no more 303 redirection. I don't think I fully understood how hash and slash options could be effectively combined until I read the latest Cool URIs for the Semantic Web. Anyhow, keep up the good work! hanks for the shout out. I did get around to taking Tom’s suggestion to provide a lookup technique that preserves the URI for concepts.

So instead of: http://lcsh.info/label/Beer followed by a redirect there is now a solr powered search http://lcsh.info/search?q=Beer Someday there will prolly be a SPARQL endpoint, but not just yet I don’t think. I’d actually like to see what the data looks like in a Talis store :-)

You ought to be able to use content negotiation to fetch application/rdf+xml and application/json for search results if you want. The HTML results are actually RDFa.

Also, I’ve switched over to using hash URIs instead of slash URIs for identifying concepts. So no more 303 redirection. I don’t think I fully understood how hash and slash options could be effectively combined until I read the latest Cool URIs for the Semantic Web.

Anyhow, keep up the good work!

]]> By: Ed Summers http://dynamicorange.com/2008/04/02/skos-linked-data-and-lcsh/#comment-1003 Ed Summers Wed, 23 Apr 2008 02:25:24 +0000 http://dynamicorange.com/wpblog/2008/04/02/skos-linked-data-and-lcsh/#comment-1003 Thanks for the shout out. I did get around to taking Tom's suggestion to provide a lookup technique that preserves the URI for concepts. So instead of: http://lcsh.info/label/Beer followed by a redirect there is now a solr powered search http://lcsh.info/search?q=Beer Someday there will prolly be a SPARQL endpoint, but not just yet I don't think. I'd actually like to see what the data looks like in a Talis store :-) You ought to be able to use content negotiation to fetch application/rdf+xml and application/json for search results if you want. The HTML results are actually RDFa. Also, I've switched over to using hash URIs instead of slash URIs for identifying concepts. So no more 303 redirection. I don't think I fully understood how hash and slash options could be effectively combined until I read the latest Cool URIs for the Semantic Web. Anyhow, keep up the good work! Thanks for the shout out. I did get around to taking Tom’s suggestion to provide a lookup technique that preserves the URI for concepts.

So instead of: http://lcsh.info/label/Beer followed by a redirect there is now a solr powered search http://lcsh.info/search?q=Beer Someday there will prolly be a SPARQL endpoint, but not just yet I don’t think. I’d actually like to see what the data looks like in a Talis store :-)

You ought to be able to use content negotiation to fetch application/rdf+xml and application/json for search results if you want. The HTML results are actually RDFa.

Also, I’ve switched over to using hash URIs instead of slash URIs for identifying concepts. So no more 303 redirection. I don’t think I fully understood how hash and slash options could be effectively combined until I read the latest Cool URIs for the Semantic Web.

Anyhow, keep up the good work!

]]> By: Peter Murray http://dynamicorange.com/2008/04/02/skos-linked-data-and-lcsh/#comment-1002 Peter Murray Thu, 03 Apr 2008 23:35:12 +0000 http://dynamicorange.com/wpblog/2008/04/02/skos-linked-data-and-lcsh/#comment-1002 The triple was eaten, probably due to an attempt to include some semantic markup (e.g. ). I meant to say: <http://lcsh.info/label/Beer> <owl:sameAs> <http://lcsh.info/sh85012832> The triple was eaten, probably due to an attempt to include some semantic markup (e.g. ). I meant to say:

<http://lcsh.info/label/Beer&gt; <owl:sameAs> <http://lcsh.info/sh85012832&gt;

]]> By: Peter Murray http://dynamicorange.com/2008/04/02/skos-linked-data-and-lcsh/#comment-1001 Peter Murray Thu, 03 Apr 2008 15:13:06 +0000 http://dynamicorange.com/wpblog/2008/04/02/skos-linked-data-and-lcsh/#comment-1001 I think the point is that there are RDF semantics for encoding this relationship -- owl:sameAs (http://www.w3.org/TR/owl-ref/#sameAs-def) -- rather than encoding that representation in the language of HTTP. So a request for the textual form of the term should send back a triple: . I think the point is that there are RDF semantics for encoding this relationship — owl:sameAs (http://www.w3.org/TR/owl-ref/#sameAs-def) — rather than encoding that representation in the language of HTTP. So a request for the textual form of the term should send back a triple:

.

]]> By: Bruce D'Arcus http://dynamicorange.com/2008/04/02/skos-linked-data-and-lcsh/#comment-1000 Bruce D'Arcus Thu, 03 Apr 2008 13:27:17 +0000 http://dynamicorange.com/wpblog/2008/04/02/skos-linked-data-and-lcsh/#comment-1000 This is a bit over my head, but if I was guessing, I'd say Rob is probably suggesting that the server explicitly say that the redirect URI is an alternate identifier. In RDF proper, for example, you'd do that using owl:sameAs. This is a bit over my head, but if I was guessing, I’d say Rob is probably suggesting that the server explicitly say that the redirect URI is an alternate identifier. In RDF proper, for example, you’d do that using owl:sameAs.

]]> By: Jonathan Rochkind http://dynamicorange.com/2008/04/02/skos-linked-data-and-lcsh/#comment-999 Jonathan Rochkind Wed, 02 Apr 2008 21:26:50 +0000 http://dynamicorange.com/wpblog/2008/04/02/skos-linked-data-and-lcsh/#comment-999 I still don't think I understand why it's wrong. A given authorized heading in the LCSH file can correspond to one and only one LCSH authority file. (Granted sometimes a random string will refer to NONE, but if it is an LCSH preferred heading, it can correspond to only one, yes?) If this is right, then I think those preferred terms ARE essentially identifiers. If flawed ones. They are alternate identifiers. As evidenced by the fact that most of our legacy systems get by by _treating_ them as identifiers. The way you look up all records attached to a given subject is only by that authorized term. That IS the legacy identifier. So I think you were exactly right in your motivation to want ed's system to respond to those identifiers. So if the preferred heading is an alternate identifier for the very same LCSH record--what's wrong with a redirect? You certainly wouldn't want the redirect for any "lead in" terms, these are not identifiers, they're just synonyms. But the authorized term? I say it's an identifier for the record. The LCSH term is too. They are both are. It's not unusual to have more than one identifier for the same object, is it? To the extent that ed's system really prefers you use one to the other--I think that preferences IS expressed by the fact that the authorized heading identifier does an HTTP redirect, but the LCCN identifier does not. I still don’t think I understand why it’s wrong.

A given authorized heading in the LCSH file can correspond to one and only one LCSH authority file. (Granted sometimes a random string will refer to NONE, but if it is an LCSH preferred heading, it can correspond to only one, yes?)

If this is right, then I think those preferred terms ARE essentially identifiers. If flawed ones. They are alternate identifiers. As evidenced by the fact that most of our legacy systems get by by _treating_ them as identifiers. The way you look up all records attached to a given subject is only by that authorized term. That IS the legacy identifier. So I think you were exactly right in your motivation to want ed’s system to respond to those identifiers.

So if the preferred heading is an alternate identifier for the very same LCSH record–what’s wrong with a redirect? You certainly wouldn’t want the redirect for any “lead in” terms, these are not identifiers, they’re just synonyms. But the authorized term? I say it’s an identifier for the record. The LCSH term is too. They are both are. It’s not unusual to have more than one identifier for the same object, is it?

To the extent that ed’s system really prefers you use one to the other–I think that preferences IS expressed by the fact that the authorized heading identifier does an HTTP redirect, but the LCCN identifier does not.

]]>