W3C home > Mailing lists > Public > www-tag@w3.org > March 2005

What do HTTP URIs Identify?

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Tue, 08 Mar 2005 19:04:31 +0000
Message-ID: <422DF73F.2090003@hplb.hpl.hp.com>
To: Tim Berners-Lee <timbl@w3.org>
Cc: www-tag@w3.org, SWBPD <public-swbp-wg@w3.org>



Summary: can we disentangle httpRange from social meaning?



Hi Tim

at the SWBPD F2F last weeek you encouraged us to look though your list
of alternatives to this question, which I took to mean:

http://www.w3.org/DesignIssues/HTTP-URI


Section 2:
[[
1 Every web page (or many of therm) are in fact themselves
representations of some abstract thing, and the URI really identifies
that thing, not a document at all.
2 There are many levels of identification (representation as a set of
bits, document, car which the web page is about) and the URI publisher,
as owner of the URI, has the right to define it to mean whatever he or
she likes;
3 Actually the URI has to, like in English, identify these different
things ambiguously. Machines have to disambiguate using common sense and
logic
4 Actually the URI has to, like in English, identify these different
things ambiguously. Machines have to disambiguate using the fact that
different properties will refer to different levels.
5 Actually the URI has to, like in English, identify these different
things ambiguously. Machines have to disambiguate using extra
information which will be provided in other ways along with the URI
6 Actually the URI has to, like in English, identify these different
things ambiguously. Machines have to disambiguate them by context: A
catalog card will talk about a document. A car catalog will talk about a
car.
7 They may have been used to identify documents up till now, but for RDF
and the Semantic Web, we should change that and start to use them as the
Dublin Core and RDF Core groups have for abstract concepts.
]]

It seems to be that there are two hard issues here, which can usefully
be separated.

1) http range
2) social meaning


The social meaning issue revolves around which resource any given URI
identifies and how that is established; whether through some process
involving the URI owner (as in early drafts of RDF concepts) or through
some process of shared vocabulary ownership, in which the community
establishes a shared meaning for URIs (which I think Peter F.
Patel-Schneider and Bijan Parsia preferred, but I probably misunderstood)

Any GETtable URIs have their interpretation narrowed to resources for
which the representation retrieved is a plausible representation of the
resource.

The http range issue potentially narrows the interpretation of
particular URIs (matching /http:[^#]*/), to information resources; but
even with such a narrowing this does not solve the social meaning
problem: e.g.
   http://www.w3.org/TR/2004/REC-webarch-20041215/
   http://www.w3.org/TR/webarch/
both currently deliver the same representations, but are different 
resources, with different social meanings, and both may need to be 
disambiguated through some process akin to your items 2-7 in your list.

I see these items 2-7 as all discussing the issue of social meaning
rather more than the issue of http range. I think the social meaning
issue is both intrinsically harder, and not as immediately pertinent as
the http range issue.

In particular, I expect I see eye-to-eye with many people that

http://purl.org/dc/elements/1.1/creator

identifies a particular RDF property, described as

"An entity primarily responsible for making the content of the resource."

without having to agree with them as to which of the reasons 2-7 in your
list legitimizes this identification.

(Personally, in this case I would argue that this identification is
validated by common usage; a reason which is omitted from your list).

i.e. the URI
http://purl.org/dc/elements/1.1/creator

is used in an interoperable way without resolving the issue of why it is 
interoperable.


Jeremy
Received on Tuesday, 8 March 2005 19:04:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:33 GMT