RE: Liberal "URI assignment policies" will create confusion?

Ossi,

> -----Original Message-----
> From: Ossi Nykänen [mailto:onykane@butler.cc.tut.fi] 
> Sent: 17 September 2003 11:38
> To: www-tag@w3.org
> Subject: Liberal "URI assignment policies" will create confusion?
> 
> 
> Dear all,
> 
> Related to the Issue metadataInURI-31 and "The use of 
> Metadata in URIs" DRAFT TAG Finding 8 July 2003 [1]:
> 
> First of all, I personally :) can easily accept _individual_ 
> statements like "Don't peek inside URIs" and "you can define 
> your own URI assignment policies" just fine, but...
> 
> /and now this discussion might get a bit academic ;-) /
> 
> +--------------------------------------------------------
> | Comparing e.g. the two TAG viewpoints:
> |
> | (1) Cool URIs don't change [2] (Good practice: URI Persistence)
> | (2) 1.1.2: "A URI assignment authority MAY publish specifications 
> | detailing its URI assignment policies." (from [1])
> |
> | ...it seems that these two together might effectively contradict (or 
> | at least provide a source of great confusion).
> +--------------------------------------------------------
> 
> And by saying things like (2) once too often, W3C might be 
> giving its authority away without a fight.

I don't think I see it the way you see it. To me (1) and (2) are orthogonal.
(1) is about persistence of the *mapping* between a URI and the resource (a
time varying mapping to a set of representations). (2) is about the policy
the authority uses to assign a name in the first place and what the
authority license the observer of a name to read into the 'spelling' of the
name - 'Don't peek' essentially licenses nothing (and in the extreme limit,
not even URI scheme distinctions).

> 
> This obviously relates to my previous comment about 
> versioning and in particularly about "substantial changes" of 
> resources [3]; in fact, I consider versioning a far more 
> important issue (and yes, a much more difficult but certainly 
> a very *practical* issue [the concrete things in life are the 
> most difficult ones since they do not directly twist around 
> the words or writings of men]).
> 
> In other words, if version history (of resources identified 
> via URIs) is not recognised/marshalled, nothing prevents 
> authors from replacing the resources they effectively want to 
> remove, e.g. with dummy resources. (Perhaps TAG would like to 
> say if this is "good" or a "bad" thing.)

I'm beginning to think that you might have resources and representations
confused.

> For instance, a widget salesman creates an advertisement page
> 
> (3) http://my.sales.example/2003/0917-widget.html

ok...

> and later decides to remove the page. Since he wants to apply 
> to TAG principles, he removes the content but reassigns the 
> URI of the previous page (e.g. via server configuration) to
> 
> (4) http://my.sales.example/default-removed.html

You will have to explain more clearly how he does that... I don't think that
you are trying to say that the URI used to name the resource changes. I
think you are possibly saying that the accessible representations do change
to have the same retrievable 'content' as that retrievable from the URI at
(4). He would be going completely against 'TAG principles' if he renamed the
resource at (3) with the name at (4) - but he is completely at liberty to
change to available representations at (3) and (4).

> (And yes, you get the idea simply by peeking inside the URIs I'm writing;)


:-)

> To some extent, this is also in concert with the use of URIs since both
> (3) and (4) can still be used (the content is however lost) 
> -- and the widget salesman can "publish specifications 
> detailing his URI assignment policies" (which might in 
> addition contradict with the rule of providing links to 
> policy document _from_ the affected resources, not vice 
> versa). The salesman could simply claim to have e.g. 
> abstracted the resource content -- after all advertisements 
> (as Things) DO have (finite) lifecycles also in the world of 
> people and sheets of paper.

The content of an advertisment can change.


> The example obviously points out an analogy with other cases too -- giving
> (too) much room for the URI assignment authorities, effectively neglecting
the style rule (1).

(1) and (2) are orthogonal. 

> In fact, a wicked, SW-aware salesman could even do less than 
> (4) and simply say that the HTTP 404 error correctly 
> represents the resource (3) in its current, natural lifecycle. ;-)

They could indeed and what would be so wicked about that?

> To me, this whole discussion seems to point out the need for 
> a simple type system for the things identified with URIs 
> (e.g. temporal/persistent, versioned/final, object/concept, 
> ...).

What... overloaded into the URI itself? Please don't go there.

> The URI scheme mechanism doesn't seem rich enough to 
> address the shared needs of the publishing/SW communities; 
> the former need(?) concrete referencing and versioning; the 
> latter need(?) constants(!), variable and parameter names. I 
> do appreciate, however, overloading the HTTP scheme due to 
> cheap extensibility issues and the relation with e.g. 
> namespace documents etc. However, URIs work better as 
> identifiers for individual resources than for resource 
> collections; collections (with internal structure to be
> recognised) should benefit from some sort of a wrapper 
> mechanism a la Dexter (see the footnote below.)
> 
> It seems that the concrete role of URIs in publishing and the 
> absract role of URIs in SW is where the SW and publishing 
> people seem to start wrestling -- a good example of this is 
> the discussion around namespaces, namespaces names and 
> namespace documents (i.e. either accusing others by causing 
> HTTP 404 (Not Found) errors or blaming the others not 
> understanding the essence of URIs...).
> 
> The borderline of making recommendations and standardising de 
> facto practices is obviously quite challenging.

:-)

Somewhere in this I think I have failed to understand your apparent
complaint... :-(

> Best regards,
> 
> --Ossi
> 
> [1] http://www.w3.org/2001/tag/doc/metaDataInURI-31.html
> [2] http://www.w3.org/Provider/Style/URI.html
> [3] http://www.w3.org/2001/tag/ilist#metadatainURI-31
> 
> _______________________________________________________________
> Footnote:
> What comes to managing evolving representations of XML-based 
> document collections (and associated binary data) in 
> practice, one possible large-scale solution might be 
> recommending (versioned) Cocoon-style sitemap descriptions 
> for describing document collections (developed mainly for Web 
> "sites" but the idea might be abstracted). This would also 
> provide a concrete framework for attaching metadata etc. to 
> resources. In a sense, this could also to some extent bridge 
> the gap between SW and publishing, as a sort of step towards 
> a "resource/thing ontology" (i.e. a coherent concept system 
> for declaring things): Versioning of collections of resources 
> has certain similarities with versioning of ontologies.
> 
> 
> --
> Ossi Nykänen                              Tel   +358 3 3115 3544
> Tampere University of Technology          Fax   +358 3 3115 3549
> DMI / W3C Finnish Office                  Email ossi@w3.org
> P.O. Box 553, FIN-33101 Tampere, Finland  Web   www.w3c.tut.fi

Stuart Williams
--

Received on Wednesday, 17 September 2003 13:26:10 UTC