Re: [ISSUE 57] Representation-source: a possible new approach to the HTTP Redirection Issue

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