- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Tue, 26 Feb 2008 11:11:42 +0100
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: noah_mendelsohn@us.ibm.com, "W3C TAG" <www-tag@w3.org>
On 25/02/2008, Roy T. Fielding <fielding@gbiv.com> wrote: > > On the other hand the relationship between a resource and > > the thing it stands for does have ambiguity - the publisher may be > > clear, but the consumer of such information is limited to making their > > best interpretation of whatever (ultimately human-readable) > > definitions the publisher has provided. > > > And that's a problem because ...? Sorry - I should have been clearer. I don't think this is a problem, at least not a problem in scope. [example snipped] > Here is the problem. People mint URIs for various reasons and rarely > decide what they mean until long after. People use URIs, and through > their use assign meaning that may have little or nothing to do with > the owner's original meaning. This mix of meanings and intentions is > always ambiguous, even when the owner does take the time to carefully > describe what they intend by the semantics of a name. Right. While defined-up-front vocabularies may look unambiguous, they're rarely set in stone, it's more a grayscale kind of thing. > Note that this entire example uses "Information Resources". > As I said throughout the earlier discussions, there is no relevant > distinction from the web's point of view between "information resources" > and "non-information resources." I agree - but would add that using Semantic Web tools, it is possible to make such a distinction (how useful that distinction is, is another matter). Those categories exist purely for the > sake of argument, based on the theory that it is somehow more important > to perceive the ambiguity between those sets than it is to perceive the > ambiguity *within* those sets. In fact, it is an entirely pointless > exercise in maneuvering closed-world assumptions, instead of facing up > to the real requirement: the Web is not a closed world. Ambiguity about things we know seems a little different than not knowing things we don't know. But either way, link traversing and getting more information is the common way of reducing the unknown. > The question isn't "can we remove ambiguity?" It should be "can we > understand a relationship given that ambiguity almost a certainty?" Hmm, I can make unambiguous logical statements about relationships between named resources easily enough. But ok, the ambiguity about what concepts or real-world objects those resources correspond remains. > > From this perspective, regular HTML links can been seen as expressions > > of (s, p, o) statements, where the predicate isn't explicitly typed. > > The relation can be typed, using the rel/rev attributes in concert > > with a HTML Meta Data profile - GRDDL is the nearest we have to a > > formalism for this. But it's common practice to use a kind of > > human-friendly implicit typing, for example using <a > > href="http://www.ics.uci.edu/~fielding/">Roy Fielding</a> to refer to > > a person. > > > Note, however, that HTML anchors do not (by default) express an "is_a" > type of relationship from the content to the identified resource. > They are usually "more_about" relationships. Fair enough. My point is that they don't *need* a precise definition of the relationship for them to be useful. > > But I'm suggesting the Semantic Web *does* need to distinguish between > > Roy the person and Roy's homepage. A reasonable RDF expression of the > > link above might be something like: > > > > <> dc:related <http://www.ics.uci.edu/~fielding/> . > > [ foaf:name "Roy Fielding"; > > foaf:homepage <http://www.ics.uci.edu/~fielding/> ] . > > > I think we are jumping back off the rails at this point. There is no > doubt that the Semantic Web needs to make logical assertions. It does > so by defining things like foaf:name and foaf:homepage in unambiguous > ways, not by restricting the identifier range and certainly not by > making assumptions about HTTP status codes. I agree. The above was true > between 1993-2000. Today, my home page is <http://roy.gbiv.com/>. > The Semantic Web should be capable of understanding that, even when > it is temporarily untrue, because time is essential to understanding > the Web. Time is tricky, but in this particular case such statements would be straightforward in RDF. > > But does the (document) Web need to distinguish between Roy the person > > and Roy's homepage? Evidently not, given the utility of simple linkage > > like that above. > > > That's not what the document Web is doing with an anchor. The only time > that we can make a valid assumption about the relationship expressed by > an HTML anchor is when the rel="" attribute is used correctly. > Likewise, there is nothing (aside from syntax issues) that prevents > less ambiguous relationships to be expressed within the same > representation, within the protocol stream, or within other > representations on the Web (like RDF). Right. Again, I can't have been clear enough - this is the point I was trying to make :-) > > The only way I can see to square this circle is to differentiate > > between two kinds of interpretation. For example: > > > > $ wget http://www.w3.org/People/Berners-Lee/card.n3#i > > ... > > HTTP request sent, awaiting response... 200 OK > > > > Web interpretation: this is somehow related to Tim > > Semantic Web interpretation: we got a 200, so this is about Tim - what > > does the RDF here say? > > > > If we'd got a 303, sure, we could follow the httpRange-14 resolution's > > interpretation. But I don't think we can realistically assume > > 200=Information Resource. I don't think this problem can be completely > > resolved with a technical trick at the HTTP layer. > > > Nobody *needs* to assume 200=Information Resource. That is another > completely artificial case for the sake of useless argumentation. > The 303 solution exists for people who do not want to imply that > their named resource can be represented. That's all it means for > a GET to return 303 (ever since 1994, when the original meaning of > "redirect with new method" was deprecated due to lack of implementation > and security issues and replaced with "redirect to see other resource"). > Knowing the nature of the resource is irrelevant. The use case for the > 303 recommendation was to avoid contradiction, not to avoid ambiguity. Ok, that gives me a nice way of summarizing my suggestion: that in the context of the traditional Web, no such contradiction is possible. So the Semantic Web should allow for this, accepting that (from the SW perspective) a representation returned may not necessarily be of the resource itself, it may only be *about* the resource. Further information (such as that contained in the document) is needed to tell the difference. Cheers, Danny. -- http://dannyayers.com ~ http://blogs.talis.com/nodalities/this_weeks_semantic_web/
Received on Tuesday, 26 February 2008 10:12:00 UTC