RE: Action-79 A review of COMURI

Dear Steven,

* Academic
Compact URI is a very practical down to earth technique.

* Tree
URI should be just an identifier. "Comuri avoids cluttering with metadata, taxonomy, semantics and similar ...", including trees.

* Immovable objects
Good to mention this: URIs should be as flat as possible. Describing a tree in a URI is a recipe for disaster as the tree might change. The tree should be described in another place, not in the URI.

* Number of shortened URIs
Minters can mint as many URI as necessary.

* Relation to DWBP
Identification (i.e., having a URI) is the first step to access data.

Thanks for your comments.

From: Steven Adler [] 
Sent: Tuesday, October 07, 2014 5:28 PM
To: Phil Archer
Subject: Re: Action-79 A review of COMURI


I had thought that short URL's were the bastard child of Twitter and the need to cram as much (t)wit as possible in 140 characters or less... ?

Manuel Tomas, your document is well written and meticulously described. ?While today the use of URI's is limited and the need for shortened forms of them may be academic, good of you to think ahead because the day will come when we have tens of millions of URI's describing all the trees, and other immovable objects in the world, with data. ?But then again, one can easily imagine a number of URI's that equals or exceeds the number of web pages that URL's may describe. ?How will shortened versions keep up the number of roots, branches, limbs, and leafs necessary to describe it all?

Finally, how does this relate to the Data on the Web BP charter and goals? ?I don't fully see the connection. ?

Best Regards,


Motto: "Do First, Think, Do it Again"

Phil Archer ---10/03/2014 08:59:40 AM---Tomas, I have finally sat down to read your work properly and make the


Phil Archer <>


Public DWBP WG <>, Manuel Tomas Carrasco-Benitez <>


10/03/2014 08:59 AM


Action-79 A review of COMURI


I have finally sat down to read your work properly and make the 
following comments (which I'm doing deliberately without reading others 
so I apologise for overlap - I want to come to this 'fresh.')

Initial comments:

The title makes clear that we're talking about URIs cf. URLs. Good. I 
wouldn't want to overlap current W3C work on URLs that is the subject of 
some disquiet (not least from me).

Others have already pointed out existing W3C work on CURIEs 

We need to be clear, I think, that we're not talking about Web sites and 
pages and all that. We're talking about URIs as resolvable identifiers.

We have a lot of competition in this space - and even more cultural 
objection to the idea that anything beginning with http:// is a 
persistent identifier. So we need to be careful and, as Makx will warn 
us (in his usual sage - ignore at your peril - manner) that we shouldn't 
allow ourselves to get drawn into a discussion here about what an 
identifier identifies. I will try hard to desist!

The rationale says:

"The most common URI pattern should be similar to shortened URI 
[SHORT-URI]; i.e., pattern-21. Indeed, the existence of URI shortening 
services is a symptom that something is wrong and that native short URIs 
are needed."

I don't agree, I'm afraid. URL shortners were developed to allow people 
to include short strings that mapped to potentially very complex URIs 
when writing e-mail or printed articles. Short URIs are brittle as the 
shorter the term, i.e. the fewer the number of path segments, the more 
likely it is that the term will have multiple uses that might conflict 
in future.

However, I do think URIs should be no longer than necessary and that in 
general, short is good. An example of a URI that is *way* too long and 
utterly unguessable is

So I imagine that I'm able to say what you as an EC official cannot - 
for an example of how not to mint URIs look no further than the Joinup 

I think statements like "Unwarranted complexity must be avoided. For 
example, only use longer URIs (third level domain, multisegment paths) 
when it cannot be avoided; many web sites can get by without language 
and format variants, so avoid this mechanism." can be made less 
confrontationally. Yes, you can avoid format variants in URIs but to do 
it you need to make use of content negotiation. A URI like either the gif or the png 
version of the image depending on conneg.

But... is unusual. We can configure that kind of thing. Most 
people have very little option to alter the set up of their online 
system and so we need to show why conneg is good and therefore why it's 
worth the effort.

Also, the Rationale section talks about Web sites - see above.

Design goals:

'Simplest possible characters such as number and lower case letters; 
base 36 recommended'

Nope, sorry. We're a global organisation and the Web is for everyone. 
There's nothing wrong with北京,中国

Which is a pointer to the fact that we should make explicit mention of 
IRIs as well. I would say it's OK to state at the top that we use the 
more common term URI and apply where relevant to IRIs, noting that 
things like case sensitivity has no meaning in many languages.

If this remains a separate document, ?we would need to think about CR 
Exit criteria - i.e. how do we prove that it has multiple independent 
implementations. IMO guidance like this is probably best done in a Note 
- so conformance is not required.

I need to spend more time looking at the later sections but those are my 
initial comments.

I don't mean to sound negative or disheartening. This is a complex issue 
and I hope that the WG can indeed some up with useful, repeating and 
practical advice - it's going to take a while.

Time to get ready for the weekly call...



Phil Archer
W3C Data Activity Lead
+44 (0)7887 767755

Received on Wednesday, 8 October 2014 12:24:51 UTC