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
