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.

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

For instance, a widget salesman creates an advertisement page

(3) http://my.sales.example/2003/0917-widget.html

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

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

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

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

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

Received on Wednesday, 17 September 2003 06:38:09 UTC