- From: Norman Walsh <ndw@nwalsh.com>
- Date: Wed, 13 Oct 2004 14:28:37 -0400
- To: "Ian B. Jacobs" <ij@w3.org>
- Cc: public-webarch-comments@w3.org
- Message-id: <87zn2qmq0a.fsf@nwalsh.com>
/ "Ian B. Jacobs" <ij@w3.org> was heard to say:
|>2.1. Benefits of URIs
|>
|> The choice of syntax for global identifiers is somewhat arbitrary; it
|> is their global scope which is important. The Uniform Resource
|
| s/which/that
Done.
|> Identifier, URI], has been successfully deployed since the
|> creation of the Web. There are substantial benefits to participating
|> in the existing network of URIs, including linking, bookmarking,
|> caching, and indexing by search engines, and there are substantial
|> costs to creating a new identification system that has the same
|> properties as URIs.
|
| The previous sentence doesn't really say why these are benefits.
| For example, "linking" might be better explained as "the ability
| to link to existing resources of value". Would it be useful to say
| a bit more about each benefit?
I think the reader will understand.
|>2.2. URI/Resource Relationships
|
| [snip]
|
|> [URI] is an agreement about how the Internet community allocates
|> names and associates them with the resources they identify. URIs are
|> divided into schemes and URI Scheme specifications define the
|> protocols by which scheme-specific URI are associated with resources
|> and take on meaning.
|
| I'm surprise that the word "meaning" has made its way back
| into the document. [I wonder if Stuart saw this....]
|
|> For example, the HTTP URI scheme (RFC2616) uses
|> DNS so that names such as "http://example.com/somepath#someFrag" take
|> on meaning by way of HTTP GET response messages from the domain
| holder
|> (or an agent they delegate to). HTTP GET is not the only way to
| obtain
|> information about a resource. A third party, for example, might
|> publish a document that purports to define the meaning of a
| particular
|> URI.
|
| I don't know what "meaning of a URI" means, and I thought we were
| able to discuss the Web Architecture without using this sort of
| phrase. The same comment applies to other uses of "meaning" in this
| section.
This is text we agreed to in Ottawa, so I'm not sure I can remove it
editorially.
Personally, I take "meaning" in this section to be used in a broad,
English-language sense, not in an RDF/semantic web sense.
|>2.2.1. URI allocation
|>
|> To avoid URI collision (§2.2.2), it is important to avoid
|> assigning the same URI to different resources.
|
| I still think that this section should define "URI collision"
| before explaining why one should avoid it. Why not move
| section 2.2.2 here?
That looks like a good idea.
| In any case, the above sentence seems like a tautology since
| "URI collision" is "assigning the same URI to different resources".
Yeah, that was a pretty poor sentence. I added it quickly to satisfy a
pedantic need to make sure that a section didn't start with a
subsection. I've improved it a bit, I think.
|>2.2.1.1. URI ownership
|>
|> URI ownership is a relation between a URI and a social entity, such
| as
|> a person or an organisation. URI Ownership gives the relevant social
|> entity rights to:
|> 1. pass on ownership of some or all owned URI to another owner--URI
|> allocation; and
|> 2. to associate a resource with an owned URI--URI assignment.
|>
|> By social convention, URI ownership delegated from the IANA URI
| scheme
|> registry IANASchemes], itself a social entity, to IANA
|> registered URI scheme specifications.
|
| I think this should be "IANA-registered".
Ok.
|> Some URI scheme specifications further delegate ownership to
|> subordinate registries or to other nominated owners, who may further
|> delegate ownership. For example, the URN Syntax scheme RFC2141]
|> delegates ownership of portions of URN space to URN Namespace
|> specifications
|
| This is the first instance of ownership being delegated to a
| specification. I would probably be useful to change
|
| "such as a person or an organisation" in 2.2.1.1 to
|
| "such as a person, organization, or specification. In the case
| of a specification, ownership ultimately lies with the
| community that maintains the specification."
Ok.
| This will also
| be helpful with respect to another proposed change below.
|
| Also, please s/organisation/organization/g (and similarly for other
| en-uk spellings).
Uhm, yes. I fixed organization. I didn't notice the others :-/
|> which themselves are registered in an IANA maintained
|> registry of URN Namespace Identifiers.
|
| I think this should be "IANA-maintained".
Ok.
|> Other URI schemes or nominated owners retain ownership within the
|> relevant scheme specification (or some other specification registered
|> in a subordinate registry) such that that specification and the
|> community that maintain it serve in the role of URI owners.
|> For
|> example, the specification of the data URL scheme RFC2397]
|> serves as owner of all data scheme URI; it does not further delegate
|> ownership of portions of data URI space. It associates each data URI
|> with an resource, a representation of which is embedded with each
|> data URI (the representation is infact the resource).
|
| The previous paragraph is _very_ hard to parse. I propose instead:
|
| Some URI scheme specifications do not provide for re-delegation of
| ownership. For example, the data URI scheme specification specifies
| that the resource identified by a data scheme URI has only one
| possible representation. The representation data makes up the URI
| that identifies that resource. Thus, the specification itself
| determines how data URIs are allocated; no re-delegation is
| possible.
Yes, I think that's an editorial improvement. I changed
"re-delegation" to "delegation" as I didn't think the 're-' added
anything.
| (Notice that I deleted uses of "URL"; not sure why it was used.)
And I restored the URL (and the bibliographic reference). The title of
the RFC uses the term URL which is why I've used it:
<p>Some URI scheme specifications do not provide for delegation of
ownership. For example,
the data URL <!-- sic --> scheme [<a href="#RFC2397">RFC2397</a>]
specification specifies...
:-)
|> URI Owners have a responsibility to avoid multiple URI assignments
|> that associate equivalent URI with multiple resources.
|
| I propose replacing the above sentence with the shorter:
|
| URI owners are responsible for avoiding the assignment of
| equivalent URIs to multiple resources.
Ok.
|> Thus, it is
|> also necessary that any approach to URI allocation, which passes
|> ownership of individual or organised sets of URI through
|> delegation,
|> ensures that ultimate ownership of a particular URI is vested in a
|> single social entity (which may be a specification, a person or an
|> organization).
|
| I don't think "it is also necessary" follows from what was stated
| above. I propose the following piece of additional rationale:
|
| If a URI scheme specification does provide for the
| re-delegation of URI ownership, it should take pains to ensure
| that ownership ultimately resides in the hands of a single
| social entity. Allowing multiple owners increases the likelihood
| of URI collisions.
Ok.
|> URI Owners may organise or deploy infrastruture to ensure that
|> representations of associated resources are available, and where
|> appropriate
|
| I think this should be "and, where appropriate, that"
Yep.
|> interaction with the resource is possible through the
|> exchange of representations.
|
|> There are social expectations for responsible representation
|> management (§3.6) [section 3.6] by URI owners, discussed below.
|> Additional 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.
|
| I think the previous sentence does not belong at the end of that
| paragraph. It refers to "approaches". I think the approaches in
| question are those related to name allocation, not those related
| representation management. Therefore, I propose that the sentence
| be moved to just after the sentence "By social convention,...".
Actually, I moved it even farther up as I think it now fits in better
with the overall introduction to 2.2.2. I also think it may be a
vacuously true sentence that we could simply delete, but I haven't
done that :-)
| [snip]
|
|>2.2.3. Indirect Identification
|
| [snip]
|
|> Suppose that nadia@example.com is Nadia's email address. The
|> organizers of a conference Nadia attends might use
|> "mailto:nadia@example.com" to refer indirectly to her (e.g., using
| the
|> URI as a database key in their database of conference participants).
|> This doesn't introduce a URI collision.
|
| s/doesn't/does not/
Ok.
| [snip]
|
|>2.3.2. Representation reuse
|>
|> Story
|>
|> Dirk is editing a web page
|
| s/web/Web/g
Bleh. But, OK.
|> and inserts a link to
|> "http://weather.example.com/2004/08/03/oaxaca" labeled
|> `Current Oaxaca Weather Forecast'.
|
| I am confused by the above sentence. Does it mean the same as:
|
| "inserts a link labeled 'Current Oaxaca Weather Forecast' that
| has URI "http://weather.example.com/2004/08/03/oaxaca".
|
|> Nadia spots the error
|
| That makes it sound like the error can be detected by looking
| at the URI. See proposed replacement text below.
|
|> and explains that the
|> resource Dirk has identified is the weather forecast for
|> 03 August 2004. The URI for the current forecast is
|> "http://weather.example.com/oaxaca", even though that URI and the one
|> he used return the same representations today because it is the third
|> of August.
|>
|> URI aliasing only occurs when more than one URI is used to identify
|> the same resource. The fact that different resources sometimes have
|> the same representation does not make the URIs for those resources
|> aliases. This occurs most commonly when a URI owner provides a URI
| for
|> both the "current version" of something and a URI for the "version at
|> a point in time," as the Oaxaca weather Web site is doing, but it can
|> occur in other ways as well.
|>
|> The distinguishing characteristic of representation reuse, as opposed
|> to aliasing, is that the underlying resources are different.
|
| I propose the following replacement text for this section.
|
| <story>
| Dirk would like to add a link from his Web site to the Oaxaca
| weather site. He uses the URI http://weather.example.com/oaxaca
| and labels his link "weather in Oaxaca on 1 August 2004". Nadia
| points out to Dirk that he is setting improper expectations for
| the URI he has used. The Oaxaca weather site policy is that the
| URI in question identifies the current weather in Oaxaca -- on
| any given day -- and not the weather on 1 August. Of course,
| one day a year Dirk's link will be correct, but the rest of the
| time he will be misleading visitors to his Web site. Nadia
| points out to Dirk that the weather site does make available a
| different URI permanently assigned to a resource describing
| the weather on 1 August 2004.
| </story>
|
| In this story, there are two resources: "the current weather in
| Oaxaca" and "the weather in Oaxaca on 1 August 2004". The
| Oaxaca weather site assigns two URIs to these two different
| resources. On 1 August 2004, the representations for these
| resources may be identical. That fact that deferencing two
| different URIs produces identical representations does not
| imply that the two URIs are aliases. URI aliasing only occurs
| when more than one URI is used to identify the same resource.
Much better. Thank you, Ian!
| [snip]
|
|>3.2.1. Details of retrieving a representation
|
| [snip]
|
|> Assuming that a representation has been successfully retrieved, the
|> expressive power of the representation's format will affect how
|> precisely the representation provider communicates resource state. If
|> the representation communicates the state of the resource
|> inaccurately, this inaccuracy or ambiguity may lead to URI
|> collision (§2.2.2). Efforts like the Semantic Web are seeking to
|> provide a framework for accurately communicating the semantics of a
|> resource in a machine readable way. Machine readable semantics may
|> alleviate some of the ambiguity associated with natural language
|> descriptions of resources.
|
| The Semantic Web is not itself an effort. I suggest:
|
| "Some communities, such as the ones developing the Semantic Web,
| seek to provide a framework for accurately communicating the
| semantics of a resource in a machine readable way."
Ok.
|>3.6. Representation Management
|
| [snip]
|
|> Just because representations are available does not mean that
|> it's
|
| s/it's/it is
Uhm, ok.
| [snip]
|
|>3.7. Supporting Navigation
|>
|> It is a strength of Web Architecture that links can be made and
|> shared; once one user has found an interesting part of the Web, they
|> can share this experience just by republishing a URI.
|
| Change "once one user has found an interesting part of the Web,
| they can share this experience just by republishing a
| URI."
|
| to
| "a user who has found an interesting part of the Web
| can share this experience just by republishing a URI."
Ok.
|>4. Data Formats
|>
|> Data formats (for example, XHTML, RDF/XML, SMIL, XLink, CSS, and PNG)
|> are agreements on the correct interpretation of representation
|> data.
|
| I find the phrase "Data formats are agreements" jarring. How
| about
|
| "A data format specification (for example, for XHTML, RDF/XML,
| SMIL, XLink, CSS, and PNG) embodies an agreement on the correct
| interpretation of representation data."
Ok.
|>4.2. Versioning and Extensibility
|
| [snip]
|
|> In the real world, language designers imperfectly address the
|> requirements as they interpret them, the requirements inaccurately
|> model the world, conflicting requirements are presented, and they
|> change over time. As a result, designers negotiate with users, make
|> compromises, and often introduce extensibility mechanisms so
|> that it's
|
| s/it's/it is/
Why are we removing all the contractions?
|> possible to work around problems in the short term. In the long term,
|> they produce multiple versions of their languages, as the problem,
| and
|> they're understanding of the problem, evolves. The resulting
|
| s/they're/their/
Right.
|> variability in specifications languages, and implementations
|
| missing a "," after "specifications".
Right.
|>4.2.3. Extensibility
|
| [snip]
|
|> Extensibility introduces variability which has an impact on
|> interoperability. However, languages which have no
|> extensibility
|
| s/which/that in the previous sentence.
Ok.
|> mechanisms will be extended in ad hoc ways that impact
|> interoperability as well. One key criteria
|
| s/criteria/criterion/
Ok.
|> of the mechanisms provided
|> by language designers is that they allow the extended languages to
|> remain conformant, increasing the likelihood of
|> interoperability.
|
| I don't know what it means for an extended language to remain
| conformant (to what?).
To the original specification.
| I propose instead:
|
| "One very useful characteristic of an extension mechanism is
| that it allow data conforming to an extended language to also
| conform to the original language, thus increasing the
| likelihood of interoperability."
|
| [One might also talk about software conformance, but that's
| included in the good practice note as it is written.]
I think the QA folks want it worded more strongly than "a useful
characteristic", but I added "to the original specification" to the
sentence as I had written it.
|>8. Acknowledgments
|
| We will add Noah to this list as well.
Done.
Be seeing you,
norm
--
Norman Walsh <ndw@nwalsh.com> | Life does not cease to be funny when
http://nwalsh.com/ | people die anymore than it ceases to be
| serious when people laugh.--George
| Bernard Shaw
Received on Wednesday, 13 October 2004 18:28:52 UTC