On Apr 3, 2008, at 10:42 AM, Richard Cyganiak wrote:
Mark,
On 3 Apr 2008, at 17:44, Mark Diggory wrote:
My question is, When referring to a thing in DSpace I'd like my
URL's to be Cooler. I'd like to be able to use them as my resource
id's, I got allot of Pushback for doing this by some in the ORE
community because they expect the URI to point at actual RDF
instances, not accidentally resolve the "real existing content"...
HTML and RDF/XML are just two different document formats. Claiming
that one is the “real existing content” while the other is just
“metadata” is silly in my eyes, this is being stuck in a pre-Web
mindset. HTML and RDF/XML are just different formats for encoding
the same information.
That made my day. Yes, working in a library group, my mind is often
trapped between these two extremes... Especially with working with
tools where others make such strong assumptions about a "thing" being
the same as its representation.
But to take this to the point of describing an actual "file", if I
have a file (lets say a pdf) at /path/too/my.pdf and I'm using
content negotiation... I suppose I could have a unique rdf
representation for that pdf that describes it, then /path/to/my.pdf
would return that rdf to rdf browsers. But what if I'm asking the
browser to also render the pdf? then the Accept header needs to
adjust to negotiate only the pdf.
Serving different document formats from the same URI (content
negotiation) has been a feature of the basic Web protocols for
many, many years.
And with that and the Semantic Web effort, seems that if OAI-ORE is
about being able to encode descriptions of complex composite digital
objects, they best account for content negotiation in their spec.
Because I feel this is a description of that resource, not a
description of a description of the resource. I'd like to be able
to say...
<rdf:RDF ... >
<rdf:Description rdf:about="http://dspace-test.mit.edu/handle/
1721.1/36383">
<dc:creator>Abelson, Harold</dc:creator>
<dc:creator>Zittrain, Jonathan</dc:creator>
<ore:describes rdf:resource="http://dspace-test.mit.edu/handle/
1721.1/36383#aggregation"/>
</rdf:Description>
<rdf:Description rdf:about="http://dspace-test.mit.edu/handle/
1721.1/36383#aggregation">
<ore:aggregates rdf:resource="...."/>
<ore:aggregates rdf:resource="...."/>
</rdf:Description>
</rdf:RDF>
This looks good to me.
But, doing this requires that the tool resolving be crossing 303
redirects or parsing HTML and extracting the location of the RDF
from there, otherwise they always resolve to the HTML rather than
the RDF whenever attempting to follow the URI. Can anyone
recommend what a best practice would be in this case?
Not sure I understand the problem. RDF-aware tools need to send a
proper Accept header anyways or they won't get any RDF out of many
Semantic Web sites. And practically all Web tools follow redirects
transparently unless you explicitly tell them not to.
I would actually propose this slightly different setup:
/handle/1721.1/36383 serves either HTML or RDF/XML, based on the
Accept header (content negotiation), directly without a redirect.
Yes that can be done.
/handle/1721.1/36383.html serves only HTML.
/handle/1721.1/36383.rdf serves only RDF/XML.
We currently have a special path for representations because the /
handle/ space is rather controlled in our application...but
/metadata/handle/1721.1/36383.html
/metadata/handle/1721.1/36383.rdf
/metadata/handle/1721.1/36383.xxx
should be workable for the moment. Eventually, hoping we do get to
reusing the same namespace to serve out the different representations...
This is the approach described here: http://www.w3.org/TR/cooluris/
#hashuri .
Thanks, it looks to be a good resource.
-Mark
~~~~~~~~~~~~~
Mark R. Diggory - DSpace Developer and Systems Manager
MIT Libraries, Systems and Technology Services
Massachusetts Institute of Technology
