W3C home > Mailing lists > Public > www-tag@w3.org > February 2008

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

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 26 Feb 2008 13:23:04 -0800
Message-Id: <C0933710-E5EC-4103-8D34-1910CA3B5746@gbiv.com>
Cc: W3C TAG <www-tag@w3.org>
To: Danny Ayers <danny.ayers@gmail.com>

On Feb 26, 2008, at 2:11 AM, Danny Ayers wrote:
> On 25/02/2008, Roy T. Fielding <fielding@gbiv.com> wrote:
>> Danny wrote:
>>> 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/> ] .


>>  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.

Again, that is confusing the role of content in an anchor href with
that of the URI in an anchor href.  The content "Roy T. Fielding" in
the above example is not the resource identifier, so the fact that
the URI does not map to me (it maps to a page about me) is not a
contradiction even if the Semantic Web is analyzing that HTML with
very strict ideals.  The anchor already matches quite well with the
RDF expression above, except that we don't know the content is a name
and we don't know the URI refers to a homepage resource.  Those are
additional details that can be supplied in RDF and/or other metadata
attributes -- they do not require changes to HTTP.

What I wanted to get across is that, IMO, the original goal of the
Semantic Web was to be the Web (in all its messyness) with additional
metadata to clarify and assert relationships and tools to take advantage
of the semantically-marked-up Web.  All of this talk about defining
"informational resource" or adding more hacks beyond the single case
where 303 is deemed necessary (avoiding contradiction) are solutions to
problems that simply do not exist.  What "kind of resource"
the 303 points to is irrelevant -- it is an independent reference to a
different URI (a URI that can have its own associated RDF).  Likewise,
the number of redirects that occur after the initial 303 and the extent
to which negotiated/generic resources are involved in the selection of
representations are irrelevant questions; each request is independent
and HTTP 200 responses to GET contain representations, not resources.

The only "change" that HTTP needs, in this regard, is redefinition
of the Link header that was removed from 2616 (over my objections).
It would be nice to have a list of applications that make use of the
Link header to supply relationships, particularly since that is the
best solution for immutable or binary content.

Received on Tuesday, 26 February 2008 21:23:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:55 UTC