Re: RDF for molecules, using InChI

Alan,
> I'm still waiting for an example that *can't* be solved using a HTTP 
> scheme. Do you have any? So far the best I have is that LSIDS point to 
> two "forks", the data and the metadata (meaning of these not clear, 
> btw). However I've already given an existence proof, in the way of a 
> proposed implementation (in another thread on this list) that can 
> accomplish the same thing.
I know you don't like Conneg.  But content negotiation does give you the 
"fork". 

A couple of years ago, I have asked a question on the LSID mailing list 
about what should be considered "metadata" and what should be "data"? 
And no one has a good answer for me.  The reason I asked that question 
at that time is this. If all my data is in RDF, what should I returned 
as data and what as metadata? And if I make an arbitrary decision, how 
can the consumer of my resource know when to call getMetadata() and when 
to call getData()?

But later I realized, our world won't be entirely in RDF.  With this 
thinking, it is easy to make such distinction that: data in RDF is 
metadata and everything else is data.  So, getMetadata() always return 
an RDF document, which describes the thing that would be returned by the 
getData().

Once you think along this way, then, content negotiation does exactly 
the same thing as LSID's getData() vs. getMetadata().  But the 
problematic part is the ambiguous relationship between the various 
representations returned via conneg.  We tend to think that

"get application/rdf+xml http://example.com/ir1"  owl:sameAs "get 
application/rdf+xml http://example.com/ir2"

because we should since they are identified by the same URI.  But in 
reality, it is very likely not.  What is interesting here is that the 
confusion arises when the resource IDed is an information resource 
because for non-IR, we need 303 redirect.  Of course, we can use 303 for 
IR as well, but then if both IR/non-IR use 303, what is the point and a 
waste?

I think TAG should step in here to clarify the issue because it is a 
issue unique to the HTTP URI that TAG is pushing forward to be the only 
URI scheme in SW.

My personal opinion is:
1) To give accept application/rdf+xml (or n3) a unique status because 
most of the time, an RDF document is something "about", but not "being" 
the resource unless the primary document is an RDF document.
2) Make a recommendation on using the same fragment ID in both RDF and 
other representations. Either make it an error or clarify the 
relationship. 

Xiaoshu

Received on Tuesday, 7 August 2007 11:30:23 UTC