RE: COMURI

Dear WG members,

Thanks for your comments and find below the response to several emails.

Regards
Tomas


* Purpose of the document
The scope is very narrow: compact URI.

So, the document could be too dry and some sections are included to put things in context and as a light tutorial.

The purpose of the document is stated from several point of view in the: abstract, rationale, scope, and design goals. Examples:

"Comuri is a return to roots: 'A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource' [RFC3986]. The Comuri key aspects are: compact identifier, direct identification (of variants and URI metadata), and ultrapersistency."

"The intention is to have compact URIs easy for the users (humans and machines)"


* Human and machine
URIs *must* be human and machine friendly: it is good for both.

The reality today is that humans {developers are also humans :-)} type a lot of URIs and IP addresses :-)

And human readbility is money: look at the prices of some domains :-)

More general, the question if computer code is for human or machine has been settled for a long time.
For example, most internet application protocols (including http) are text-based (human readable) though theoretically binary (only machine readable) could be better.

It goes in the spirit of literate programming
   https://en.wikipedia.org/wiki/Literate_programming


* Mnemonic URI
URI should be mnemonic as stated to  "... avoids cluttering with metadata, taxonomy, semantics and similar".

In particular, the metadata should be obtained by other mechanisms and not encoded into the URI.


* Connection to data
The connection to data is stated. For example:

 "This work is in the context of the Data on the Web Best Practices Working Group and hence data requirements are very much taken into account. In particular, the URI ultrapersistency to accompany the requirement of data preservation, though data preservation is out of scope."


There are sections on:
        8.2 Data archival
        8.3 Data packing
        8.4 Big and small data
        8.5 Online and offline data
            8.5.1 Online data
            8.5.2 Offline data
        8.6 Static and dynamic data
            8.6.1 Static data
            8.6.2 Dynamic data

    9. Multilingual data


* Terminology
The terminology follows the standards and new terms are aligned with existing terms; nothing is redefined.

For example, the term "direct identification" is created because is needed to name this mechanism. The word "identification" is used because this is the one in RFC3986 and "direct" because of is semantics. Also, "indirect indentification" is in RFC3986.

A significant part of writing specifications defining concepts. Having explicit definitions is one approach. For example, as in XML
  http://www.w3.org/TR/REC-xml


* Data archival
Data archival itself is out of scope. The section is to put into context the URI usage:

 - Web servers are taken off-line: how one identify the archived web servers?
 - The original URIs are gone and one might (or not) have redirection servers.
 - What happen to the URIs of the offline web servers without http mechanisms?


* Specification and wiki
The draft specification or wiki can be used for the discussion, though a specification format is more disciplined and it tend to better highly the issues. Anyhow, at the end of the day one has to write the specification, so the sooner one starts the better.


* Comments
Stating the obvious, the document is draft, so please comment; in particular:

 - General purpose
 - Concrete issues
 - Terminology
 - Concept definition
 - Rephrasing, better explanation
 - Examples
 - Errors

If possible, point to specific sections and suggest solutions.

Received on Saturday, 27 September 2014 12:36:18 UTC