Parties who wish to communicate must agree upon a shared set of
identifiers and on their meanings.
This is untrue for some reasonable meanings of "meaning", as Pat Hayes
has argued from time to time. You could say instead:
"Parties who wish to communicate must agree on the practical
effects of using certain identifiers."
or
"Parties who wish to communicate must agree upon a shared set of
identifiers and (to a reasonable degree) on their meanings."
That is: some ambiguity of meaning is both reasonable and
unavoidable. I don't think an unqualified "agree" normally means
"partially agree".
Does http://weather.example.com/oaxaca identify the weather report for
just Oaxaca or for the Oaxaca region? When it starts to matter, you
can start to build a shared understanding of which it is. But you
can't banish those ambiguities until you notice them. There's also a
school of design where you choose not to banish them, even when you
see them, until you know they matter.
Overtaken by events.
issue hawke2: Section 2: Full agreement not required for communication
error decided 2004-02-13
[Section 2] assumes that identification and retrievability are the same thing.
Given the extensive use, starting with namespaces, but continuing with the
identification of XSLT and XQuery functions, and so on, of using URIs to
identify non-retrievble and abstract entities, this conflation is problematic
at best.
Decided at Ottawa f2f. (No action.) The new text about information
resources is believed to address this issue.
issue schema2: [Section 2] Unwise confluence of identification and retrievability
error decided 2004-03-04
Section 2, introductory paragraphs. In the introduction to this
section, the failure of the document to make any serious attempt to
define the term 'resource' begins to bite you -- and more to the
point, begins to cause problems for the reader. I recognize that it's
difficult to define 'resource' well, but I believe it essential that
you try. If definition proves absolutely impossible, you can of
course take it as an undefined primitive notion, but to make that
approach useful I think you would need to specify explicitly the
relations which are postulated as holding between resources and other
primitive notions.
In the current draft, you are making things too easy on yourselves;
the document suffers.
Some questions one might hope to have some light shed on by either a
definition or by a non-defining description of resource as a primitive
notion:
How many resources are there, or how many could there be?
Can resources be created or come into existence at a particular
point in time?
Can resources cease to exist?
Can a set of resources be a resource?
Can a part of a resource be a resource?
Do all users of the Web operate with the same set of resources,
or is it possible for one user to identify three resources
where another identifies only two, without either of them being
in error?
Who determines the identity of a resource?
If the question arises whether two URIs designate the same
resource, can there be an authoritative answer to the question,
or is it a judgement question like the question 'Is "love" an
adequate English rendering for the Greek word "agape"?', on which
every thoughtful observer may form an independent opinion?
It is clear that various parts of the architecture document assume
that some resources have owners. Do any resources have multiple
owners? Do any resources lack owners?
issue msm8: WD-webarch-20031209, Section 2, introductory paragraphs: The term 'resource' needs to be defined
error raised 2004-03-04
Section 2 para 3 says
When a representation uses a URI (instead of a local identifier)
as an identifier, then it gains great power from the vastness of
the choice of resources to which it can refer.
This suggests that URIs have the advantage, compared to local
identifiers, of being more numerous. But if we assume that both URIs
and local identifiers are finite-length strings without any length
restriction we need worry about, then both sets are enumerably
infinite and there is a one-to-one mapping between them, so that they
have exactly the same cardinality and neither is any more vast than
the other.
I suspect that what is meant here is that URIs have the advantage of
being dereferenceable; this is true of some URIs, but not, I think, of
all.
Overtaken by events.
issue msm9: WD-webarch-20031209, Section 2 para 3: The vastness of URI space
error decided 2004-03-04
Section 2, Principle: URI assignment says: "A resource owner SHOULD
assign a URI to each resource that others will expect to refer to."
In order to comply with this principle, it seems to be necessary for
resource owners to know what resources they own, or (equivalently) to
know, of each thing they own, whether it is a resource or not. It
doesn't seem plausible to expect compliance with this principle if
"resource" is not defined more informatively than it is defined in
this document.
It may also be noted in passing that this principle also requires that
resource owners predict what other actors will expect; it would be
nice if the principle could be reformulated without requiring owners
to perform such predictions.
Note also that if resources can be any "items of interest" (as stated
by section 1), it may be impossible for a resource owner to provide
URIs for every resource which may be an item of interest. If there is
an owner of the real numbers, for example, that owner cannot comply
with the principle enunciated here. If anyone owns an infinite set of
items of interest, and if sets of such items are thought to be
themselves potential items of interest, then that owner cannot, in
principle, provide URIs for all items of interest: the power set of an
enumerably infinite set is not enumerable, and neither URIs nor any
other finite names can be provided for all the members of a
non-enumerable set.
I wonder if some slightly less demanding principle ought to be
enunciated.
Overtaken by events.
issue msm10: WD-webarch-20031209, Section 2: Assigning URIs to resources others will expect to refer to
error decided 2004-03-04
Parties who wish to communicate must agree upon a shared set of
identifiers and on their meanings.
This is false. A baby communicates distress and discomfort to his or
her parents without there being any identifers, or even any
identification going on on the part of the baby. I might be able to
communicate that this large bolder crushing my leg should be removed
by the stout and helpful non-english-speaking lass beside me by making
somewhat spastic gesticulations. Or, in a more structured way, I might
point at the bolder, or wap the bolder, and make a little rolling
motion with my hands.
A number of editorial comments followed
Overtaken by events.
issue parsia5: LC Comment, Section 2: Agreement on identifiers
error decided 2004-03-05
The identification mechanism for the Web is the URI.
Presumably this isn't *quite* right, as there is a need for some
idenification mechanisms that are not URI based in order to associate
(some, at least) URIs with resources for subsequent reidentification.
Also, for example, host names identify things very critical to the
functioning of the web, and yet, aren't URIs. Etc.
Overtaken by events.
issue parsia6: LC Comment, Section 2: Identification mechanism of the Web
error decided 2004-03-05
A URI must be assigned to a resource in order for agents to be able
to refer to the resource.
Even restricted to software agents, this is false.
_x foaf:mbox <mailto:bparsia@isr.umd.edu>.
Allows an OWL Reasoner to refer to me (since foaf:mbox is an
InverseFunctionalProperty). (While there was a URI involved, it wasn't
assigned *to me*.) I can make or refute assertions about me in this
way.
Overtaken by events.
issue parsia7: LC Comment, Section 2: On requirement to assign a URI to a resource
error decided 2004-03-05
Resources exist before URIs;
If URIs are strings, and string are abstract mathematical entities
(i.e., a kind of data structure) independant of their physical
instantiation, then, reasonably, URIs have always existed, so any
particular URI has existed before some recently come into existent
Resources. I'm not even sure of the point of such metaphysical
statements. Or imagine I have, oh, a programming language where I have
URI objects (a subclass of String). Let's say I want to use a URI to
identify some other objects in my system. Does this claim require that
(in pseudopython):
my_object_uri = URI('http://blahblah.com/blah') #The URI now
exists!
my_funky_object = FunkyObject() #Now the Resource in question
exists.
my_object_uri.assigned_to(my_funky_object)
is broken in some way? Why would this matter?
issue parsia8: LC Comment, Section 2: On resources existing before URIs
clarification raised 2004-03-05
a resource may be identified by zero URIs.
Ah, this is what you mean? It's not very happy either. I take it you
mean that some resource might *not* be identified by *any* URI. Cool.
And given my above example, it might still be possible for agents to
refer to it. Naturally, it's often a good idea to give various
resources a URI! For example, I don't think it's possible (or, at
least, easy) to *link* to something in a machine readable way in HTML.
So, give such resources URIs, please. I think it's quite possible to
make the sensible point without appeal to broken metaphysics.
Actually, the rest of the paragraph seems quite good and
sensible.
Overtaken by events.
issue parsia9: LC Comment, Section 2: On resources being able to have zero URIs
error decided 2004-03-05
Principle: URI assignment.
A resource owner SHOULD assign a URI to each resource that others will
expect to refer to.
I would recommend the TAG study FOAF because that community has made a
different choice (i.e., to rely a lot on inverseFunctionalProperties).
Aside from that, I think this principle misses an important point:
Formats and protocols should (often?) be designed to use URIs. This
encourages URI assignment by adding value to such assignment.
Overtaken by events.
issue parsia10: LC Comment, Section 2: On URI assignment
error decided 2004-03-05
First para: [[Parties who wish to communicate must agree
upon a shared set of identifiers and on their meanings.]]
"identifiers (names for things)"?
issue manola8: Add "(names for things)" after "identifiers"?
clarification raised 2004-03-10
Parties who wish to communicate must agree upon a shared set of
identifiers and on their meanings. The ability to use common
identifiers across communities motivates global identifiers in Web
architecture. Thus, Uniform
Resource Identifiers ([URI], currently being revised) which are global
identifiers in the context of the Web, are central to Web
architecture.
Constraint: Identify with URIs
The identification mechanism for the Web is
the URI.
A URI must be assigned to a resource in order for agents to be
able to refer to the resource. It follows that a resource should be
assigned a URI if a third party might reasonably want to link to
it, make or refute assertions about it, retrieve or cache a
representation of it, include all or part of it by reference into
another representation, annotate it, or perform other operations on
it.
When a representation uses a URI (instead of a local
identifier) as an identifier, then it gains great power from the
vastness of the choice of resources to which it can refer. The
phrase the "network effect" describes the fact that the usefulness
of the technology is dependent on the size of the deployed Web.
Resources exist before URIs; a resource may be identified by
zero URIs. However, there are many benefits to assigning a URI to a
resource, including linking, bookmarking, caching, and indexing by
search engines. Designers should expect that it will prove useful
to be able to share a URI across applications, even if that utility
is not initially evident.
The scope of a URI is global; the resource identified by a URI
does not depend on the context in which the URI appears (see also
the section about URIs in
other roles). Of course, what an agent does with a URI may
vary. The TAG finding "URIs, Addressability, and the use of HTTP GET and
POST" discusses additional benefits and considerations
of URI addressability.
Principle: URI assignment
A resource owner SHOULD assign a URI to each
resource that others will expect to refer to.
This principle dates back at least as far as Douglas Engelbart's
seminal work on open hypertext systems; see section Every Object Addressable in [Eng90].
In section 2.1, "URI Comparisons", I understand the meaning of the paragraph
which begins "Applications may apply rules ...". It means that if your
application makes assumptions about URI equivalences based on details not
covered in the specification, then it's your responsibility if any problems
develop from that. What I don't understand is the term "authority component" in this sentence:
For example, for "http" URIs, the authority component is case-insensitive.
The TAG agreed with the Editor's change to include parenthetical.
issue karr1: What does "authority component" mean?
clarification decided 2003-12-21
The statement "one might reasonably create URI's that ..." in the following passage may be inappropriate, as the preference for viewing a resource in Italian or Spanish should be communicated as meta information within the context, for which mechanisms such as CC/PP are being developed. To countenance the use of non-unique URI's for such a purpose is unwise.
The TAG believes that it is useful to indicate that there are
two resources (one Spanish and one Italian) but to add to the
example some discussion of content negotiation.
issue diwg2: Don't communicate language info in URIs (in example)
error decided 2004-02-25
The AWWW says that one may conclude that agents or representations are
each referring to the same resource if they are using identical URIs.
But that's problematic; it suggests that the relation between
resources and URIs is in some sense timeless and static. Once a URI
has been coined to identify a given resource, it can only ever
identify precisely that resource; else, we have to embrace the
willy-nilly change problem.
The TAG believes the reviewer's question is addressed by
section 3.6.2 of the document.
issue clark3: Willy-Nilly Resource Change
clarification decided 2004-02-26
When determining the uniqueness of a URI, is the fragment identifier
considered part of the identifying URI? If there is an argument list, does
the ? and what follows constitute part of the unique URI?
issue laskey2: What determines URI uniqueness?
clarification raised 2004-03-01
...For example, the parties responsible for weather.example.com should not
use both "http://weather.example.com/Oaxaca" and
"http://weather.example.com/oaxaca" to refer to the same resource; agents
will not detect the equivalence relationship by following specifications.
and
... Agents should not assume, for example, that
"http://weather.example.com/Oaxaca" and "http://weather.example.com/oaxaca"
identify the same resource, since none of the specifications involved
states that the path part of an "http" URI is case-insensitive.
While correct, I felt this was potentially a little confusing. The first
example did not seem well chosen to reflect the point I think is being
made. Suggest:
...For example, the parties responsible for weather.example.com should not
use both "http://weather.example.com/Oaxaca" and
"http://weather.example.com/Mexico?city=Oaxaca" to refer to the same
resource; agents will not detect the equivalence relationship by following
specifications.
Hmmm, maybe there's a third point to be made here, namely that the party
responsible for some domain should avoid using different URIs with small,
easily overlooked differences?
issue klyne6: Clarification about point on agents detecting equivalence relationships
clarification raised 2004-03-05
[[URI producers should be conservative about the number of
different URIs they produce for the same resource. For example, the
parties responsible for weather.example.com should not use both
"http://weather.example.com/Oaxaca" and
"http://weather.example.com/oaxaca" to refer to the same resource;
agents will not detect the equivalence relationship by following
specifications. On the other hand, there may be good reasons for
creating similar-looking URIs. For instance, one might reasonably create
URIs that begin with "http://www.example.com/tempo" and
"http://www.example.com/tiempo" to provide access to resources by users
who speak Italian and Spanish.]]
Why does the first sentence refer to "URI producers" that "produce" URIs
rather than "resource owners" that "create" them (which would be more
consistent with earlier text). I also note that words "assign",
"create", and "produce" (and possibly others) are all used for what
seems to be the same idea.
Also, the rest of this illustration seems to have a funny interaction
with the URI opacity principle in Section 2.5 (especially the discussion
there about the travel example), since the Section 2.1 text above seems
to suggest there is value in being able to convey information to an
accessing "agent" (a human in this case) via the form of the URI itself
(i.e., if URIs are to be totally opaque to the "agent", why would there
be value in using one language over another?). Of course, this may be
just another problem in allowing "agent" to refer to people. However,
the problem seems somewhat more acute if the result of dereferencing
URIs in different languages is the retrieval of the report in the
corresponding languages because, while this kind of makes sense, it also
invites determining the language of the report from the language of the URI.
issue manola12: URI producers or owners? Relationship to opacity principle?
Evidence of confusion about "agent" including "people"?
clarification raised 2004-03-10
2nd para. The first sentence establishes
that character-by-character inequality doesn't mean that the resource
referred is different. But the subsequent sentences say basically the
opposite (that this is the most straightforward way to find resource
equality). Break into two paragraphs, or otherwise improve wording
to less confuse the reader.
Overtaken by events.
issue i18nwg8: Sentences seem contradictory
error decided 2004-03-18
3rd para. The casing example for weather.example.com/Oaxaca is a
bit obscure. Perhaps spell out the fact that case sensitivity matters
to some systems?
issue i18nwg9: Case example unclear.
clarification raised 2004-03-18
For instance, one might reasonably create URIs that begin with
"http://www.example.com/tempo" and "http://www.example.com/tiempo" to
provide access to resources by users who speak Italian and
Spanish."
It is nice to see an i18n-related example. However, there are all
kinds of issues with this. This is not necessarily a good way to
organize information in different languages on a server, in
particular if the information is highly parallel. It may be
better to find another example, for example with two English
words. Also, 'tempo' is an English word with a different
meaning. Perhaps German "Wetter" is better?
issue i18nwg10: Don't recommend organizing information by language.
clarification raised 2004-03-18
4th para.
"Likewise, URI consumers should ensure URI
consistency. For instance, when transcribing a URI, agents should not
gratuitously escape characters. The term "character" refers to URI
characters as defined in section 2 of [URI]".
The definition of
'character' in the first sentence is not clarified by section 2 of
the URI draft, which deals with details such as percent escaping of
characters. Section 1 of the URI draft *points to* a definition of
'character'.
This is an area where the presence of IRI would be welcome.
It might be more useful to describe what "gratuitious" means in
this context (there is currently no definition; we *think* it
means "don't escape characters unless it breaks usability", i.e.
I would expect to see %20 instead of space (because space breaks
the URI semantically).
issue i18nwg11: Mention IRIs?
clarification raised 2004-03-18
Web architecture allows resource owners to assign more than one
URI to a resource.
Constraint: URI
uniqueness
Web architecture does not constrain a Web
resource to be identified by a single URI.
Thus, URIs that are not identical (character for character) do
not necessarily refer to different resources. The most
straightforward way of establishing that two parties are referring
to the same Web resource is to compare, as character strings, the
URIs they are using. URI equivalence is discussed in section 6 of
[URI]
Good practice: URI aliases
Resource owners should not create arbitrarily
different URIs for the same resource.
URI producers should be conservative about the number of
different URIs they produce for the same resource. For example, the
parties responsible for weather.example.com should not use both
"http://weather.example.com/Oaxaca" and
"http://weather.example.com/oaxaca" to refer to the same resource;
agents will not detect the equivalence relationship by following
specifications. On the other hand, there may be good reasons for
creating similar-looking URIs. For instance, one might reasonably
create URIs that begin with "http://www.example.com/tempo" and
"http://www.example.com/tiempo" to provide access to resources by
users who speak Italian and Spanish.
Likewise, URI consumers should ensure URI consistency. For
instance, when transcribing a URI, agents should not gratuitously
escape characters. The term "character" refers to URI characters as
defined in section 2 of [URI].
Good practice: Consistent URI usage
If a URI has been assigned to a resource,
agents SHOULD refer to the resource using the same URI, character
for character.
Applications may apply rules beyond basic string comparison that
are licensed by specifications to reduce the risk of false
negatives and positives. For example, for "http" URIs, the
authority component is case-insensitive. Agents that reach
conclusions based on comparisons that are not licensed by relevant
specifications take responsibility for any problems that result.
Agents should not assume, for example, that
"http://weather.example.com/Oaxaca" and
"http://weather.example.com/oaxaca" identify the same resource,
since none of the specifications involved states that the path part
of an "http" URI is case-insensitive.
See section 6 [URI] for more
information about comparing URIs and reducing the risk of false
negatives and positives. See the section on future directions for
approaches other than string comparison that may allow different
parties to assert that
two URIs identify the same resource.
Following the lessons of the "deep linking" debacle, it might be good to
say explicitly what rights "URI ownership" does or does not confer. This
is somewhat addressed later, but it might be good to say something in this
section.
The Editor will include a forward link from 2.2 to 3.6.3.
issue booth2: What rights does "URI ownership" confer?
clarification decided 2004-01-06
The reviewer raised a number of points about URI ownership
and authority in sections 3.4 para 1 and para 2.
issue stickler7: Section 3.4, para 2: URI ownership questions
error raised 2004-02-03
Given all these problems I don't see how the architectural principles of
the World Wide Web can be so dependent on resource ownership. Many of the
uses of ``resource owner'' in the document do not make sense at all and
need to be removed from the document.
The term "Resource owner" has been replaced with "URI owner".
issue pps1: Ownership and authority
error decided 2004-02-12
Section 2.2, bulleted list, first item. It would be useful, I think,
if this were expounded at greater length. It is not necessarily clear
to all readers (it is, for example, not entirely clear to me) how the
hierarchical delegation here postulated follows from the wording of
the specifications defining the HTTP and mailto schemes.
Overtaken by events.
issue msm11: WD-webarch-20031209, Section 2.2, bulleted list, first item: Delegation of authority in hierarchical URIs
error decided 2004-03-04
Whatever the techniques used, except for the checksum case, the
agent has a unique relationship with the URI, called URI ownership.
Here is what I can find on what's an "agent", prior to this
passage:
Within each of these systems, agents (people and software)
strate typical behavior of Web agents \x{2014} people or software (on
behalf of a person, entity, or process) acting on this information
space. Software agents include servers, proxies, spiders, browsers, and
multimedia players.
So, an agent is a person or a program. Thus, every http uri has,
supposedly, one, and only one, person or program that is its owner.
However, institutional ownership seems possible, as is joint ownership.
issue parsia14: Various types of ownership
clarification raised 2004-03-05
The social implications of URI ownership are not discussed here.
However, the success or failure of these different approaches depends
on the extent to which there is consensus in the Internet community on
abiding by the defining specifications.
First you say that the social implications of URI ownership are *not*
discussed here, then go on to discuss some social implications. Don't
do that.
I don't believe the second statement of that quote, at least on many
interpretations, and I've objected to its use in various technical
arguments, some with TAG members. If this passage is to be a stick to
beat me with in technical debate in W3C working groups, then I
strenuously object to it, especially without substantial explication
and clarification. So, I make the strong comment that I want this line
struck. I object to it.
issue parsia15: Social implications of URI ownership.
error raised 2004-03-05
[[The requirement for URIs to be unambiguous demands that
different agents do not assign the same URI...]]
Now we have *agents* assigning URIs rather than, e.g., resource or URI
owners. It's not clear that this is consistent with prior discussion.
issue manola13: Can agents assign URIs? Or should this be "use"?
clarification raised 2004-03-10
[[The concept of URI ownership is especially visible in the case of the
HTTP protocol, which enables the URI owner to serve authoritative
representations of a resource.]]
This text is pertinent to the point raised earlier about resource vs.
URI ownership, and might be expanded on a bit to clarify that
relationship. In particular, when dealing with URIs that have
retrievable representations, it is straightforward to demonstrate
ownership; non-owners can't determine what is returned when
dereferencing such URIs, while owners can.
issue manola14: Clarify relationship between resource / URI ownership
clarification raised 2004-03-10
The requirement for URIs to be unambiguous demands that different agents do not
assign the same URI to different resources. URI scheme specifications assure this using a
variety of techniques, including:
- Hierarchical delegation of authority. This approach,
exemplified by the "http" and "mailto" schemes, allows the
assignment of a part of URI space to one party, reassignment of a
piece of that space to another, and so forth.
- Random numbers. The generation of a fairly large random number,
used in the "uuid" scheme, reduces the risk of ambiguity to a
calculated small risk.
- Checksums. The generation of a URI as a checksum based on a
data object has similar properties to the random number approach.
This is the approach taken by the "md5" scheme.
- Combination of approaches. The "mid" and "cid" schemes combine
some of the above approaches.
The approach taken for the "http" URI scheme follows the pattern
whereby the Internet community delegates authority, via the IANA
URI scheme registry [IANASchemes] and the DNS, over a set of URIs with
a common prefix to one particular owner. One consequence of this
approach is the Web's heavy reliance on the central DNS
registry.
Whatever the techniques used, except for the checksum case, the
agent has a unique relationship with the URI, called URI
ownership. The phrase "authority responsible for a URI"
is synonymous with "URI owner" in this document.
The social implications of URI ownership are not discussed here.
However, the success or failure of these different approaches
depends on the extent to which there is consensus in the Internet
community on abiding by the defining specifications. The concept of
URI ownership is especially visible in the case of the HTTP
protocol, which enables the URI owner to serve authoritative
representations of a resource. In this case, the HTTP origin
server (defined in [RFC2616])
is the agent acting on behalf of the URI owner.
AWWW abjures URI ambiguity; but in trying to think carefully about this,
I've realized that it's important to distinguish two kinds of URI ambiguity:
diachronic and synchronic. The AWWW only addresses the former kind, and I
think it should address the latter kind, too.
I'd like to see some language in the AWWW about avoiding synchronic
ambiguity by avoiding the "URI overloading" mistake with content
negotiation.
issue clark2: What kinds of ambiguity are there?
clarification raised 2004-02-26
The architecture document needs to do a better job of explaining what a
resource is in this context. (See email for more info)
Decided at Ottawa f2f. Added 2.5.2 Representation reuse.
issue schema3: [Section 2.3] Clarity required on nature of "resource"
error decided 2004-03-04
Section 2.3 says that the ambiguous *use* of URIs is to be avoided
(though, I'll point out, that the Good Practice is ambiguous between
ambiguous URIs and ambiguous *use* of URIs).
Of course, certain ambiguity doesn't matter, e.g., replicating Quine, I
might use a URI to refer to me, the human being, and someone else to
refer to the collection of undetatched people parts. As long as all our
uses *align* in (all) our interactions, we're fine, ambiguous
assignment or not.
Sorry for the quick digression into philosophy of languages, but,
really, at this time of night, I feel a little justified in turn around
:)
Overtaken by events.
issue parsia12: Ambiguous use of URIs v. URI Ambiguity?
error decided 2004-03-05
Hierarchical delegation of authority. This approach, exemplified by
the "http" and "mailto" schemes, allows the assignment of a part of URI
space to one party, reassignment of a piece of that space to another,
and so forth.
First use of 'URI space', which is undefined. I see 'information
space', 'uniform address space', and, of course, 'namespace'. As far as
I can tell, only 'namespace' has a definition (and it's not in this
doc, which is fine). Perhaps this is only editorial. A URI space seems
clear (a set of URIs? why not say that then?), but I did spend some
time wondering if it was the same as an infromation space or address
space. *Are* you using unambiguous phrases here? Are they aliases? Is
there a problem with either defining terms or using only one where
there's only one concept? Some principles of the web apply well to
technical prose.
issue parsia13: Use of term "URI Space"
clarification raised 2004-03-05
URI ambiguity should not be confused with ambiguity in natural language.
I'm not sure what this sentence is trying to say (what is meant here by
"confused with"). From what follows, I think the intent is to say
something like "justified by", in which case I think something like:
URIs should not be permitted the ambiguity that occurs in natural language.
[...existing text...]
This flexibility is not available to URIs, which should be defined to refer
to a single concept.
[Later,] I ran across this from TimBL in one of the Tag IRC logs, which seems to
capture the point more effectively.
Suggested text for 2.6: Whereas human communication tolerates such
ambiguity, machine processing does not. Strictly, the above URI as
identifies the information resource, some hypertext document. RDF
applications which use it for describing properties of that page are in
order; those who use its URL to directly assert properties of the whale are
using it inconsistently.
issue klyne8: Unclear point about ambiguity in natural language; is the point
about machine processing?
clarification raised 2004-03-05
[[URI ambiguity should not be confused with ambiguity in
natural language. The English statement "'http://www.example.com/moby'
identifies 'Moby Dick'" is ambiguous because one could understand the
phrase "Moby Dick" to refer to distinct resources: a particular printing
of this work, or the work itself in an abstract sense, or the fictional
white whale, or a particular copy of the book on the shelves of a
library (via the Web interface of the library's online catalog), or the
record in the library's electronic catalog which contains the metadata
about the work, or the Gutenberg project's online version]]
This example illustrates an ambiguous natural language statement, but
it's not clear that it doesn't also illustrate an ambiguous URI, since
the text doesn't say anything about how example.org, or other parties
citing http://www.example.com/moby, actually intepret it.
issue manola15: Does example *also* illustrate ambiguous URI usage?
clarification raised 2004-03-10
URI ambiguity. This may imply or suggest that natural language
differences in the representation of a resource are considered
bad. There should be examples of both good and bad ambiguity (or in
WebArch terminology, different but consistent representations of the
same resource as opposed to the use of a single URI for different
resources), with language negotation being a good example and wholly
different resources being a bad example
issue i18nwg14: Show examples of good and bad ambiguity
clarification raised 2004-03-18
Just as a shared vocabulary has tangible value, the ambiguous
use of terms imposes a cost in communication. URI
ambiguity refers to the use of the same URI to refer to
more than one distinct resource.
Good practice: URI
ambiguity
Avoid URI ambiguity.
URI ambiguity should not be confused with ambiguity in natural
language. The English statement "'http://www.example.com/moby'
identifies 'Moby Dick'" is ambiguous because one could understand
the phrase "Moby Dick" to refer to distinct resources: a particular
printing of this work, or the work itself in an abstract sense, or
the fictional white whale, or a particular copy of the book on the
shelves of a library (via the Web interface of the library's online
catalog), or the record in the library's electronic catalog which
contains the metadata about the work, or the Gutenberg project's online version.
[[In Web architecture, URIs identify resources. Outside
the bounds of Web architecture specifications, URIs can be useful for
other purposes, for example, as database keys...]]
It seems to me this paragraph mixes a few things. Just because a URI is
used as a database key doesn't necessarily mean it's being used for a
different purpose. If a URI is used as a key in a relational table that
associates metadata with the Web resources identified by those keys, and
does so correctly (i.e., distinguishes between metadata about Nadia and
metadata about her mailbox), it seems as if this is the *same* use of
the URI (to identify a Web resource), even though it may also be used in
the database to identify a distinct row in the table. Moreover, the
database might exhibit URI ambiguity in the same way the Web might,
e.g., by mixing metadata about both Nadia and her mailbox in the same
row. At the same time, the use of "mailto:nadia@example.com" as an
identifier for Nadia rather than her mailbox seems just as likely to
occur in a Web context as in this database one (people seem to want to
do it in RDF, for example; or is this not the part of the Web you're
talking about?).
issue manola16: Paragraph on other uses of URIs is confusing
clarification raised 2004-03-10
Good practice: URI opacity: This says
"Agents making use of URIs MUST NOT attempt to infer properties of the
referenced resource except as licensed by relevant specifications."
Earlier, the document defines 'agent' as both humans and machines.
This good practice is not too difficult to follow for agents
(although this seems to disallow e.g. Google to consider pieces
of an URI in their algorithms, e.g. the 'weather' and
'oaxaca' in 'http://weather.example.com/oaxaca'; we're not sure
disallowing this is intended or makes sense).
However, this practice is *impossible* to follow for humans: It's
just completely impossible to look at http://weather.example.com/oaxaca
and NOT interfering that this may be about 'weather' or 'oaxaca'.
The WebArch document itself is using this connection all the time.
This is important in connection with IRIs.
Overtaken by events.
issue i18nwg16: Good practice on URI opacity impossible to follow for humans.
error decided 2004-03-18
In Web architecture, URIs identify resources. Outside the bounds
of Web architecture specifications, URIs can be useful for other
purposes, for example, as database keys. For instance, the
organizers of a conference might use "mailto:nadia@example.com" to
refer to Nadia. While this usage is not licensed by Web
architecture specifications, in the context of the conference, all
parties may agree to that local policy and understand one another.
Certain properties of URIs, such as their potential for uniqueness,
make them appealing as general-purpose identifiers. In the Web
architecture, "mailto:nadia@example.com" identifies an Internet
mailbox; that is what is licensed by the "mailto" URI scheme
specification. The fact that the URI serves other purposes in
non-Web contexts does not lead to URI ambiguity. URI ambiguity
arises a URI is used to identify two different Web
resources.
Authors of specifications SHOULD NOT introduce a new URI scheme when
an existing scheme provides the desired properties of identifiers and
their relation to resources
The inverse (converse?) is also true - you should reuse a scheme and
protocol when they
do have the desired properties. It might be a good idea to reference
RFC3205 in this regard.
Overtaken by events.
issue rosenberg3: Reuse appropriate URI schemes (and protocols)
proposal decided 2004-04-21
In the URI "http://weather.example.com/", the "http" that
appears before the colon (":") names a URI scheme. Each URI scheme
has a normative specification that explains how identifiers are
assigned within that scheme. The URI syntax is thus a federated and
extensible naming mechanism wherein each scheme's specification may
further restrict the syntax and semantics of identifiers within
that scheme.
Examples of URIs from various schemes include:
- mailto:joe@example.org
- ftp://example.org/aDirectory/aFile
- news:comp.infosystems.www
- tel:+1-816-555-1212
- ldap://ldap.example.org/c=GB?objectClass?one
- urn:oasis:names:tc:entity:xmlns:xml:catalog
While the Web architecture allows the definition of new schemes,
introducing a new scheme is costly. Many aspects of URI processing
are scheme-dependent, and a significant amount of deployed software
already processes URIs of well-known schemes. Introducing a new URI
scheme requires the development and deployment not only of client
software to handle the scheme, but also of ancillary agents such as
gateways, proxies, and caches. See [RFC2718] for other considerations and costs
related to URI scheme design.
Because of these costs, if a URI scheme exists that meets the
needs of an application, designers should use it rather than invent
one.
Good practice: New URI schemes
Authors of specifications SHOULD NOT introduce
a new URI scheme when an existing scheme provides the desired
properties of identifiers and their relation to resources.
Consider our travel
scenario: should the authority providing information about the
weather in Oaxaca register a new URI scheme "weather" for the
identification of resources related to the weather? They might then
publish URIs such as "weather://travel.example.com/oaxaca". When a
software agent dereferences such a URI, if what really happens is
that HTTP GET is invoked to retrieve a representation of the
resource, then an "http" URI would have sufficed.
If the motivation behind registering a new scheme is to allow a
software agent to launch a particular application when retrieving a
representation, such dispatching can be accomplished at lower
expense via Internet Media Types. When designing a new data format,
the appropriate mechanism to promote its deployment on the Web is
the Internet Media Type.
Note that even if an agent cannot process representation data in
an unknown format, it can at least retrieve it. The data may
contain enough information to allow a user or user agent to make
some use of it. When an agent does not handle a new URI scheme, it
cannot retrieve a representation.
The Internet Assigned Numbers Authority
(IANA) maintains a registry [IANASchemes] of mappings
between URI scheme names and scheme specifications. For instance,
the IANA registry indicates that the "http" scheme is defined in
[RFC2616]. The process for
registering a new URI scheme is defined in [RFC2717].
The use of unregistered URI schemes is discouraged for a number
of reasons:
- There is no generally accepted way to locate the scheme
specification.
- Someone else may be using the scheme for other purposes.
- One should not expect that general-purpose software will do
anything useful with URIs of this scheme; the network effect is
lost.
Note: Some URI scheme specifications (such as
the "ftp" URI scheme specification) use the term "designate" where
the current document uses "identify."
TAG issue siteData-36 is about expropriation of naming
authority.
- the 2nd sentence of the 2nd paragraph in section 2.5 says "For
robustness, Web architecture promotes independence between an identifier
and the identified resource.". Should it not say "... the identified
resource and its representations."?
The reviewer retracted the issue.
issue baker1: Independence between identifier and resource, or representations?
clarification decided 2004-03-05
It is tempting to guess the nature of a resource by inspection of a
URI that identifies it. However, the Web is designed so that agents
communicate resource state through representations, not identifiers. In
general, one cannot determine the Internet Media Type of
representations of a resource by inspecting a URI for that resource.
For example, the ".html" at the end of "http://example.com/page.html"
provides no guarantee that representations of the identified resource
will be served with the Internet Media Type "text/html". The HTTP
protocol does not constrain the Internet Media Type based on the path
component of the URI; the server is free to return a representation in
PNG or any other data format for that URI."
First sentence talks about inferring the *nature* of a *resource* by
URI inspection (i.e., inferring that <http://ex.org/#BijanThePerson>>
rdf:type Person. from the URI alone). But the third sentence through
the rest of the paragraph talks about inferring the Mimetype of the
*representation* of the (state of) the resource. If you mean to
discourage both practices, some serious reworking is in order.
issue parsia17: Do you mean resource or representation?
clarification raised 2004-03-05
Resource state may evolve over time. Requiring resource owners to
change URIs to reflect resource state would lead to a significant
number of broken links. For robustness, Web architecture promotes
independence between an identifier and the identified resource.
I just wonder how this is different from:
Resources may come and go over time. Requiring resource owners to
abandon URIs to reflect resource non-existence woudl lead to a
significant number of broken links. For robustness, Web architecture
promotes independence between an identifier and the identified
resource."
Of course, you might say that abandoning URIs isn't what's required,
but rather maintaining legacy state. But then you've either changed the
resource (to something "representing" the nonexistence resource), or
you return representations reflecting the state of a nonexistence
resource. Of which there isn't any.
(Note that I'm not talking about imaginary entities, but ones who have
ceased to exist.)
The logic of avoiding broken links suggests that temporal URL ambiguity
might be useful for Web robustness (which might not be the same as
correctness).
issue parsia18: Temporal URL ambiguity useful for Web robustness?
clarification raised 2004-03-05
Good practice: URI opacity.
Agents making use of URIs MUST NOT attempt to infer properties of the
referenced resource except as licensed by relevant specifications.
This says nothing about not inferring properties of the retrieved
representations.
issue parsia19: Ok to infer properties of retrieved representations?
clarification raised 2004-03-05
[[URI producers should be conservative about the number of
different URIs they produce for the same resource. For example, the
parties responsible for weather.example.com should not use both
"http://weather.example.com/Oaxaca" and
"http://weather.example.com/oaxaca" to refer to the same resource;
agents will not detect the equivalence relationship by following
specifications. On the other hand, there may be good reasons for
creating similar-looking URIs. For instance, one might reasonably create
URIs that begin with "http://www.example.com/tempo" and
"http://www.example.com/tiempo" to provide access to resources by users
who speak Italian and Spanish.]]
Why does the first sentence refer to "URI producers" that "produce" URIs
rather than "resource owners" that "create" them (which would be more
consistent with earlier text). I also note that words "assign",
"create", and "produce" (and possibly others) are all used for what
seems to be the same idea.
Also, the rest of this illustration seems to have a funny interaction
with the URI opacity principle in Section 2.5 (especially the discussion
there about the travel example), since the Section 2.1 text above seems
to suggest there is value in being able to convey information to an
accessing "agent" (a human in this case) via the form of the URI itself
(i.e., if URIs are to be totally opaque to the "agent", why would there
be value in using one language over another?). Of course, this may be
just another problem in allowing "agent" to refer to people. However,
the problem seems somewhat more acute if the result of dereferencing
URIs in different languages is the retrieval of the report in the
corresponding languages because, while this kind of makes sense, it also
invites determining the language of the report from the language of the URI.
issue manola12: URI producers or owners? Relationship to opacity principle?
Evidence of confusion about "agent" including "people"?
clarification raised 2004-03-10
[[It is tempting to guess the nature of a resource by
inspection of a URI that identifies it. However, the Web is designed so
that agents communicate resource state through representations, not
identifiers.]]
This is another place where including people in the definition of
"agents" seems to create a possible difficulty. If agents include
people, then people quite frequently communicate information about the
nature of a resource by inspection of URIs, and it's very helpful. For
example, "http://weather.example.com/oaxaca" certainly suggests that the
resource it identifies has something to do with the weather in oaxaca
(as is noted further on), and that's very useful information (e.g., when
people pass those URIs around). That's certainly information about "the
nature of a resource", and Internet Media Types aren't the only things
relevant to people. This all, of course, reads much better if "agents"
are restricted to software. Pursuing this point in the subsequent text:
[[Agents making use of URIs MUST NOT attempt to infer properties of the
referenced resource except as licensed by relevant specifications.]]
This is good practice for software "agents". For people "agents", given
the "must not", how do you propose to stop them?
Further to this point, the text goes on:
[[The example URI used in the travel scenario
("http://weather.example.com/oaxaca") suggests that the identified
resource has something to do with the weather in Oaxaca. A site
reporting the weather in Oaxaca could just as easily be identified by
the URI "http://vjc.example.com/315". And the URI
"http://weather.example.com/vancouver" might identify the resource "my
photo album."]]
This is certainly true. But while it's good practice for software to
treat URIs opaquely, it seems to me that given the discussion in Section
2.1, which seems to license creating "descriptive" URIs in different
languages to enable people speaking those languages to more easily
access a resource (and which reflects the use of text in URIs as a means
for conveying information to people), you might want to suggest that,
given this "dual purpose" of URIs, it's *not* good practice to use the
URI "http://weather.example.com/vancouver" to identify the resource "my
photo album", even though one could, and it would be irrelevant to software.
Overtaken by events.
issue manola17: "Agent" that includes "people" source of confusion
error decided 2004-03-10
It is tempting to guess the nature of a resource by inspection
of a URI that identifies it. However, the Web is designed so that
agents communicate resource state through representations, not
identifiers. In general, one cannot determine the Internet Media
Type of representations of a resource by inspecting a URI for that
resource. For example, the ".html" at the end of
"http://example.com/page.html" provides no guarantee that
representations of the identified resource will be served with the
Internet Media Type "text/html". The HTTP protocol does not
constrain the Internet Media Type based on the path component of
the URI; the server is free to return a representation in PNG or
any other data format for that URI.
Resource state may evolve over time. Requiring resource owners
to change URIs to reflect resource state would lead to a
significant number of broken links. For robustness, Web
architecture promotes independence between an identifier and the
identified resource.
Good practice: URI
opacity
Agents making use of URIs MUST NOT attempt to
infer properties of the referenced resource except as licensed by
relevant specifications.
The example URI used in the travel scenario
("http://weather.example.com/oaxaca") suggests that the identified
resource has something to do with the weather in Oaxaca. A site
reporting the weather in Oaxaca could just as easily be identified
by the URI "http://vjc.example.com/315". And the URI
"http://weather.example.com/vancouver" might identify the resource
"my photo album."
On the other hand, the URI "mailto:joe@example.com" indicates
that the URI refers to a mailbox. The "mailto" URI scheme
specification authorizes agents to infer that URIs of this form
identify Internet mailboxes.
In some cases, relevant technical specifications license URI
assignment authorities to publish assignment policies. For more
information about URI opacity, see TAG issue metaDataInURI-31.
While I suspect that the older language for describing these semantics
had its own problems, I would be happier either with (1) its return or
(2) some further amplification or clarification of the existing
language.
The answer to the reviewer's question is "yes to 1."
The TAG believes that no change to the document is
required.
issue clark1a: Fragment Identifier Semantics
clarification decided 2004-02-26
See writeup from KC.
issue clark1b: Conflicting secondary resources
clarification raised 2004-02-26
Story
When navigating within the XHTML data that Nadia receives as a
representation of the resource identified by
"http://weather.example.com/oaxaca", Nadia finds that the URI
"http://weather.example.com/oaxaca#tom" refers to information about
tomorrow's weather in Oaxaca. This URI includes the fragment
identifier "tom" (the string after the "#").
The fragment
identifier of a URI allows indirect identification of a
secondary resource by
reference to a primary resource and additional information. The
secondary resource may be some portion or subset of the primary
resource, some view on representations of the primary resource, or
some other resource. The interpretation of fragment identifiers is
discussed in the section on media types and fragment identifier semantics.
See TAG issues abstractComponentRefs-37 and DerivedResources-43.
There remain open questions regarding identifiers on the Web.
The following sections identify a few areas of future work in the
Web community.
The integration of internationalized identifiers (i.e., composed
of characters beyond those allowed by [URI]) into the Web architecture is an important
and open issue. See TAG issue IRIEverywhere-27 for discussion about work going
on in this area.
Proposal" Knowing two URIs identify the same resource does not, however,
mean they are interchangeable. For example, Oaxaca might have
several government-run weather stations, and the measurements take
from each of these might be available from both
weather.example.org and weather.example.com.
The first might call a particular station
http://weather.example.org/stations/oaxaca#ws17a
while the second calls it
http://weather.example.com/rdfdump?region=oaxaca&station=ws17a
These two URIs would both identify the same resource, a certain
collection of weather measuring equipment. They are owl:sameAs
each other. But an attempt to dereference them might well produce
different content produced by different organizations (probably
based originally on the same government-supplied data), so a user
agent which substituted one for the other would be serving its
user poorly.
Overtaken by events.
issue hawke7: 2.7.2. Assertion that Two URIs Identify the Same Resource
proposal decided 2004-02-13
Emerging Semantic Web technologies, including the "Web Ontology
Language (OWL)" [OWL10], define
RDF [RDF10] properties such as
sameAs to assert that two URIs identify the same
resource or functionalProperty to imply it.
