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
