- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 24 Jun 2011 08:03:20 +0100
- To: www-tag@w3.org
On 6/23/11 4:08 PM, Xiaoshu Wang wrote: > On 6/22/11 8:06 PM, "Jonathan Rees"<jar@creativecommons.org> wrote: > >> On Thu, Jun 16, 2011 at 7:35 PM, Xiaoshu Wang<xiao@renci.org> wrote: >>> For me, I don't care because if there is no ontology that classify >>> everything in the world into IR and if there is no reasoner that >>> implements >>> code to check every URI's response code and triggers subsequence >>> inference, >>> following httpRange-14 (even if I can) is simply a waste of time. >>> Hence, I >>> doubt I will ever do it. But for those who cares, 2xx code is cheaper >>> than >>> 303. >>> Xiaoshu Wang >> The reason for the httpRange-14 rule is that it lets us write metadata >> for things on the web in a direct way, and be understood. > http://example.com/xiaoshuwang is a Person. > > Assuming the URI respond with 200. Address of a Resource that carries (bears) representation. Now, let's say we name an Object: http://example.com/xiaoshuwang#this, we now have a Name that resolves to a Representation. Depending on the actual Resource itself (e.g. its actual data representation format and associated semantics e.g. of the kind in RDF) one could infer that: Name: http://example.com/xiaoshuwang#this resolves to a representation of its referent. Address: http://example.com/xiaoshuwang resolves to a resource bearing (carrying) the representation (e.g. an EAV/SPO graph pictorial). Of course, it could be a plain old human readable HTML document too :-) Now if one opts not to terminate the URI Name with a # we have to use HTTP 303 to implement the >1 level of indirection so that Name and Address are disambiguated. Kingsley > What is not 'indirect' and what cannot > be understood? > >> The >> inference rule you are looking for is: If U is a dereferenceable >> absolute URI, and M(<U>) for some metadata M, and a retrieval of U >> yields a representation Z, then M(Z). E.g. if an information resource >> has dc:title "Little mouse", then its associated representations do, >> too. Conversely, if M(Z) consistently for Z retrieved from U, then >> M(<U>). > I don't quite understand it. But whatever it is: do you think any reasoner > will implement the necessary code to check how every URIs in an RDF doc > get responded? > >> I agree with you: if nothing important follows about<U> from >> retrievals of U, then there is absolutely no reason to assume anything >> about the relation between<U> and U. But metadata is important and it >> does follow. Maybe my logic is a bit too simplistic, but I think >> metadata is the previously unarticulated justification for the rule. >> And it is very consequential - statements of license and authorship >> can have quite serious ramifications. There is no metaphysics >> involved. > What is metadata (or for that matter, what is data)? Excuse for me picking > bones from egg. But I do get confused with the word metadata, especially > in RDF world. Given an RDF doc, can you tell part of them is metadata and > the other not? > > >> The rule is misstated and that has confused everyone; it seems to be >> about an "information resource" type distinction but it makes a whole >> lot more sense if it is about the relation between a URI and the >> particular metadata subject (information resource, document, whatever) >> *served from that URI* - not to just any old information resource, but >> that particular one. I think the creators of the resolution took this >> as a given. >> >> I've written this up here: http://www.w3.org/2001/tag/awwsw/ir/20110517/ >> >> Now, if you have a better way to write this kind of metadata, then you >> don't need the httpRange-14 rule, but we absolutely need *some* way to >> write metadata and I have yet to see anyone propose a better one. All >> the alternatives I've come up with are very ugly as they involve an >> occurrence of the URI as a string. >> >> You ask what we gain from this; it's the ability to talk easily, >> naturally, and consequentially about what's on the web. Practically >> every rdfs:seeAlso, owl:imports, foaf:homePage, dc:creator, >> xhtml:license depends on this convention. There's a ton of metadata >> out there, often doing its job inconspicuously. People usually follow >> the httpRange-14 rule without even thinking about it. That's why it >> has so few champions. Without the rule, there is huge FUD about every >> use of all of these properties, very serious ambiguity when a page >> could be about a page, and we may as well just stop writing metadata >> the way we do now. This is the direction we're headed if we can't get >> stronger agreement. > If I receive a message saying: > > U1 a :Person. > > I don't see anything difficult to understand it. And if I try to > dereference U1, I should expect something about a person. If not, I would > think that the person who authorized the U1's response is sloppy, or has > mal-intension. Whether I got back 200 or not doesn't affect my > understanding at all. > > Of course, this is not what you have in mind. You were thinking the case > such as: > > U1 a :Person. > U1 foaf:homePage U1. > > People's first reaction is: this is wrong. But, what if this is the > author's intention. That is: he is using U1 to reference the entity that > is both a Person and a Web Page. (Please do not say that such a thing does > not exist because then you must define the word 'existence'. For this, I > recommend reading Quine's "On What There is".) > > I am not recommending people to practice like this. But my point is: the > Web is about communication. We might not believe other's theory, but who > are we to tell them "to shut up"? > > If the author of U1 wants to describe the webpage of U1 without raising > unnecessary confusion, he can still do it with > > U1 a :Person. > <__:webpage> ex:webpageof U1. > <__:webpage> foaf:homePage U1. > <__:webpage> dc:title "blah, blah". > > Is it difficult? I don't think so. Is it clear? I think so. > > Please note, I am not suggesting replacing 303 use this approach. If > people don't feel comfortable of b-node, then can by all means use 303. > The point that I want to stress is: the ambiguity problem resides in how > we describe things. It has nothing to do with HTTP protocol. > > >> (And by the way a lot of people think 303 means not-an-IR. There is no >> justification for this idea and it is false in practice. A good >> example is the 303 responses served from dx.doi.org, where the URIs >> name documents without any commitment as to whether they are or aren't >> on the web.) >> >> I'm not trying to persuade you it's a good design (although if you >> think otherwise I'd like to see what you'd substitute as a metadata >> notation), I'm just trying to get you to stop saying the rule is >> inconsequential or without serious purpose. > The original purpose of httpRange-14, I guess, is to avoid ambiguity. But > ambiguity can only be cleared with more ontological assertions. > httpRange-14 has raised more confusion/debate. Except transferring > ambiguity to a different term, what problem it has solved? > > Xiaoshu > > > -- Regards, Kingsley Idehen President& CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Received on Friday, 24 June 2011 07:03:55 UTC