On Sun, Oct 5, 2008 at 5:24 PM, Pat Hayes <phayes@xxxxxxx> wrote:
> On Oct 4, 2008, at 9:56 PM, Alan Ruttenberg wrote:
>> On Sat, Oct 4, 2008 at 8:46 PM, Pat Hayes <phayes@xxxxxxx> wrote: (01)
>>> It is resolved by 'content negotiation', a similar technique used for
>>> example to decide which language version you get of a multi-language-
>>> edition newspaper. To regard these editions as a single resource is
>>> considered good Web practice according to the W3C Architectural
>>> guidelines, but the extension of this to the HTML/RDF distinction is
>>> currently more controversial. So this might be good practice,
>>> depending on how the current debates about RDF and content negotiation
>>> finally settle out. In the meantime one should probably treat it as
>>> provisionally good practice, or maybe experimental good practice. (02)
>> Ahem.
>> There is not a whiff of content negotiation, which I don't like (03)
> Oh, sorry. I spoke too soon. (04)
>> because it makes it confusing to figure out what resource the URI names. (05)
> ?? Why does content negotiation make this difficult? The whole idea of
> content negotiation is to decide upon alternative representations of a
> single resource. If you use 200 codes with content negotiation, there is a
> single resource involved, denoted by the URI, which can have alternative
> representations (eg as RDF or HTML). I see nothing confusing about that.
> True, if you wish to refer to one of these documents in particular, you
> ought to use a different URI, but again, that seems unproblematic. (06)
Perhaps you are right that content negotiation is not the
problem. Maybe it's that there seems no way to determine what a
uri denotes in the framework in which content negotiation
lives. We know that these are different "representations" (not in
the KR sense, btw) of the same thing, but have no way of
discovering what the thing is. Perhaps it's that the content
negotiation adds insult to injury. (07)
It is the case, at least in the world I live in, that the
encoding of information is as important as the content that is
encoded. The problem is that by not having a discipline of making
it clear what the name denotes it becomes difficult to
distinguish those cases where the thing the URI denotes is the
document versus the thing that the document is about. Rather than
leaving that continued confusion in place it seems better to
adopt a discipline in which each thing is named differently,
including the the documents, from the getgo. (08)
Using a browser to navigate web pages is not the same activity as
building an infrastructure by which machines can communicate
effectively. The property "unproblematic" does not transfer from
one situation to the other. (09)
>> I do not consider using content negotiation good practice, even
>> provisionally. (010)
> Well, as you know, others differ. I said it was still being debated. (011)
Yup. And this was my contribution to the debate. (012)
>> The specific series of events that happens when the browser does a get
>> of http://purl.obofoundry.org/obo/OBI_0000225 (013)
>> purl.obofoundry.org is a cname for purl.org, so purl.org is where a
>> request is sent. (014)
>> purl.org has a redirect set so that a request to
>> http://purl.obofoundry.org/obo/OBI_0000225 results in a directive that
> says - look for what you are looking at
> http://sw.neurocommons.org/obiterm/OBI_0000225 (a 302 response) (015)
>> (here's the purl information
>>
>http://purl.obofoundry.org/maint/display.pl.cgi?noedit=on&purl=/obo/OBI_0000225&id=nobody) (016)
>> A get of http://sw.neurocommons.org/obiterm/OBI_0000225 returns a 303
>> response, which says: I can't give you the resource you want (the
>> "universal" investigation site) how about this instead, where "this"
>> is http://ashby.csail.mit.edu/cgi-bin/obiterm?ref=OBI_0000225 (017)
>> This protocol - using a 303 response to indicate that the entity named
>> is not the sort of thing you can "get" over the network - is called
>> httpRange-14 http://www.w3.org/2001/tag/issues.html#httpRange-14 (018)
> According to http-range-14, a 303 redirect response tells you absolutely
> nothing about what the URI denotes. This is in contrast to a 200-range
> response, which does tell you something: that the URI denotes something you
> can access over the network, to wit, the very "information resource" that
> emitted the representation that accompanies the response code. (019)
You are correct in that a 303 doesn't tell you that the thing
can't be "get" over the network, however I don't think that the
200 distinction holds up in any clear way. First, what does
'access' mean? I've not heard a consistent distinction make
between what sort of things are those for which a 200 response is
appropriate and which are not. Even things that I've thought were
perfect candidates, e.g. a file, are not considered by the
architects of this policy to be those sorts of things. (020)
But to speak more clearly, *I* use a 303 response in place of a
200 response because a 200 response would either a) imply
something that is false - namely that the thing itself can be
conveyed over the wire. or b) be confusing since there isn't a
protocol by which we can determine what the thing denoted is. (021)
> This is the 'normal' case which underlies almost every successful HTTP Web
>transaction.
> I guess I don't see why you need to invoke http-range-14 at all, in order to
> map between RDF and HTML. They are both 'information resources', after all. (022)
There is a difference between a document and the interpretation
of a document. I want to say sometimes that the URI denotes the
document and other times that the URI denotes what the document
is about. There is no need to make this distinction in the usual
browsing experience by people. I believe that there *is* a need
to make the distinction for machine communication systems, which
is what I take the Semantic Web to be about. (023)
>> Note: the relation between what you ask for and what you are given is
>> currently underspecified. Here one might consider it "provisional good
>> practice" that one serves RDF/XML that contains statements about the
>> resource. (024)
> Indeed. Or, more generally, serves information about the resource in
> whatever form might be most useful to the requestor, perhaps in many forms,
> to be resolved by cont... oh, sorry, I forgot. (025)
Yes, this is a problem that I alluded to when I said it was
underspecified. I'd like that firmed up. (026)
>> A get on that URI retrieves OWL statements about the resource. The OWL
>> is serialized as RDF/XML. RDF/XML is XML, and so can have a stylesheet
>> directive that says how it can be transformed to be displayed in a
>> browser. This is similar in spirit to the model/view distinction in
>> engineering user interfaces. The model is the RDF, the view is
>> generated from the model. The stylesheet directive looks like this: (027)
>> <?xml-stylesheet type="text/xsl"
>> href="http://ashby.csail.mit.edu/cgi-bin/obiterm.xsl?ref=OBI_0000225";?> (028)
>> The browser then gets
>> http://ashby.csail.mit.edu/cgi-bin/obiterm.xsl?ref=OBI_0000225 in
>> order to get that transform, then applies it to the RDF/XML to
>> generate HTML that it can display. (029)
>> OK, I see how you do it. Still, seems to me that content negotiation would
>> be simpler and more in conformance with TAG recommendations than using
>> stylesheets, which are restricted to XML. (030)
Um, is RDF/XML not XML? (Actually, it's not clear it is, which is
kind of nuts). I actually have to have the mime type be XML
rather than RDF/XML so that the stylesheet is used, because it
doesn't seem to be specified that an RDF/XML document is_a XML
document. (031)
>> For those that might think that this looks like a lot of traffic to
>> generate the page, I'll remind that there are a variety of ways that
>> this same information can be retrieved much more efficiently, for
>> example the whole OBI OWL file
>> (http://purl.obofoundry.org/obo/obi.owl), or as a query against the
>> Neurocommons triple store at http://sparql.neurocommons.org/ . For the
>> single dereference of a citable name, we consider it more important
>> that we try as best possible to not confuse what the URI denotes (032)
> Can you really make sense of your explanation, above, in terms of URI
> denotations? (033)
The URI denotation is something that arises from the intention of
the entity that uses it, not from any technical mechanism (except
insofar as that mechanism is an implementation that is faithful
to the intention). The role of technical mechanisms is to try to
enable the conveyance of that denotation - that is, to establish,
as best possible, a means by which it is possible for a receiver
of a message with that URI to reconstruct the denotation. For
machine to machine interaction this is harder, for a number of
reasons. (034)
Because of the ambiguity between documents and the things they
denote in current practice (such as with content negotiation, or
with use existing use of LSIDs) I think we need to be much less
ambiguous about what each URI denotes. I'm familiar with your
arguments that unambiguity is impossible, but that doesn't mean
that one can't be less ambiguous than we are now, and that there
are not benefits to doing so. (035)
-Alan (036)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (037)
|