Re: RDF for molecules, using InChI

On Aug 7, 2007, at 7:29 AM, Xiaoshu Wang wrote:

> 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".
> .. . 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()?

Yup. I think that this is one of the problems with the LSID spec. An  
important difference is that data is constrained to be immutable  
according to the spec. One consequence of this was sometimes the  
distinction between data and metadata is simply that: One can change,  
and the other not. Other times the dictum that the data never changes  
is ignored. If I understand Mark Wilkinson's use of the term, the  
metadata is (at least) information about something that someone  
*other* than the producer of the information is providing.

> 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().
Plausible.
> 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.

The W3C use of "representation" doesn't make sense to me. So it's  
hard for me to get past a sentence that uses that concept.

> 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.

I'm not following you in the above.

> 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.

Might work.

> 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.

I'm not a fan of frag ids because the establish anarchic behavior  
seems impossible to change, and even with the use of it, at least  
insofar as the practice of having a single document being returned  
for multiple fragids and then having to fish out the relevant portion  
goes, I don't see a workable solution.

> Xiaoshu

Received on Thursday, 9 August 2007 03:34:51 UTC