Re: What are proper URIs for RDF representations of real existing content

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

Received on Friday, 4 April 2008 01:41:58 UTC