I Really Don’t Know

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.

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.

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:

.

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>

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!

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!