Re: [entity-resolution] Re: Fwd: Review of OASIS Artifact IdentificationRequirements (includes URN, namespace updates)

[Robin Cover <robin@oasis-open.org>]

On Tue, 28 Jun 2005, Norman Walsh wrote:
[high-level observations, appended below]

Norm (and TC),

I'm very pleased to see your initial feedback contribution,
and look forward to the additional "level of detail[ed
comment"] you will bring to this draft design document
prepared by the OASIS TAB.

I feel certain that experience you bring from working on
the W3C Technical Architecture Group (TAG), as well as
your personal depth of technical expertise in this
area, will prove invaluable in making the new OASIS
Object/Artifact/Identifier Guidelines/Requirements
document a much better piece of work.  But why is
your comment being published to the entity-resolution
TC list?

I have sent a request to Patrick Gannon (one of my
bosses, and my Ueber-boss in the OASIS context), and
to Eduardo Gutentag (OASIS BOD, OASIS TAB) asking for
consideration of a proposal to immediately place this
document into public review. The PDF document of
course is now public in draft form [1], but I think
we need a review forum that is open to all OASIS
participants (anyone with a Kavi password), and
ideally, open to non-members who are willing to
offer technical comment.

[1]
http://lists.oasis-open.org/archives/entity-resolution/200506/pdf00001.pdf
http://lists.oasis-open.org/archives/entity-resolution/200506/msg00016.html
http://lists.oasis-open.org/archives/entity-resolution/200506/pdf00000.pdf

The naming document has been in draft within the TAB for
many months (almost 2 years), and although a couple earlier
versions were referenced on the OASIS Chairs list (subscribable
ONLY by Chairs), it seems not to have attracted the
attention it deserves, and apparently has not benefited
from detailed critical review by a broad range of technical
experts who represent different community interests, technical
perspectives, and industry experience.

Grateful for the recent editorial leadership from the
current TAB members, and for the work of people no
longer serving on the TAB, I think it's now past time
to place the document into a forum for wider review.

Unofficially, I have contributed some hours of review
and feedback since about March 2005, but I don't
feel the process for evaluating feedback and
incorporating design changes is efficient, effective,
or otherwise optimal given the subject matter. That is
not any criticism of the TAB members who have worked
hard to get the draft to this stage -- but perhaps a
criticism of the decision to develop this key
specification within the confines of the TAB in the
first place.

Some of the technical problems being addressed
involve subtle design choices and require intimate
familiarity with key IETF, W3C, and ISO specifications:
that's a task for several dozen -- not a half-dozen --
engineers. Some of the decisions being made are very
consequential because they impact a wide range of
users and use cases. Getting this document "right" IMO will
require domain expertise from a much broader base of experts.

I have suggested the possibility of using the OASIS
'members-discuss' list as one venue for email-based review.
Maybe a public wiki or other tool would be better.
Doesn't matter as long as the document, (a) its
implicit [? published] set of requirements, and (b) its
proposed solutions are vetted in public forum.

</opinion>

Robin Cover
[submitted NOT in any official capacity and not representing
any corporate entity]

---


Norm said:

> / Mary McRae <marypmcrae@gmail.com> was heard to say:
> |   This was supposed to have been forwarded to the TC for review; I
> | didn't see it come across the email list so I'm (re)posting.
> 
> I had the impression that some private review was being solicited
> before this document was surfaced in the public, but I am delighted to
> see that I was mistaken.
> 
> The entity resolution list is public, so in the interest of making my
> comments public, I am reposting them here:
> 
> I have a number of technical comments about the draft, but before I go
> into that level of detail, I want to begin with a painful, high-level
> observation: I think this document approaches the metadata problem it
> seeks to solve in fundamentally the wrong way. I say that with
> trepidation and a horrible sense of responsibility since it clearly
> draws some of its inspiration from the work that Karl Best and I did
> in 2001. In the intervening years, I have changed my position[1] on
> the central question of "names and addresses" such that I no longer
> support URNs at all for the sorts of artifacts Karl and I were
> attempting to name.
> 
> The URN registration process requires that a new URN scheme describe
> its purpose and the procedure used to construct a URN in that scheme
> in exact detail. That is why RFC 3121 describes an ontology of
> artifacts and a procedure for constructing compound names (URNs) from
> the artifacts, their titles, types, versions, and other metadata.
> 
> I think adapting that methodology for naming artifacts with http: URIs
> is a recipe for disaster. The process is rigid, brittle, confusing,
> and unnecessary. The public will not understand it, TCs will find it
> crushingly burdensome, and it will not scale. Please don't do it.
> 
> At the end of the day, a member of the public, looking at a document
> produced by an OASIS TC, needs to be able to quickly, easily, and
> unambiguously answer some simple questions such as:
> 
>   1. What is this?
>   2. Who produced it?
>   3. Is it the most recent version?
>   4. If it's not the most recent, where is the most recent?
>   5. What is its status?
>   6. When was it produced?
>   7. What has the TC done since it produced this?
> 
> I propose that you adopt a much simpler alternative. It is not without
> points over which there may be controversy, but it has proven to be
> robust and scalable.
> 
> First, decide what metadata you will require every TC to associate
> with every document that it publishes officially. (As a corollary, you
> want to make sure that every draft that is distributed unofficially is
> distinct from all the official drafts.)
> 
> The current draft lays out most of this metadata (and some other
> elements that I don't think are necessary under this alternative
> proposal):
> 
>   1. A TC Name
>   2. A Title
>   3. A Version, if appropriate
>   4. A Revision, if appropriate
>   5. A Stage
>   6. An Abstract
>   7. A Language
> 
> I think it would make sense to include a few more things:
> 
>   8. An Editor (or Editors) Name (or Names)
>   9. A Date
>  10. A Copyright
>  11. Some sort of IPR statement
>  12. Links to any appropriate feedback URIs or email addresses
> 
> It may be valuable to associate some boilerplate with the document
> as well.
> 
> Second, require that every TC provide all of this data in a machine
> readable form. I propose that the most straightforward way to do this
> is to require that the normative version of each specification be
> expressed in XHTML and to require that the "title page" of that XHTML
> document contain this metadata in a form that is both visible to the
> reader and can be extracted by a tool.
> 
> This may be a point of controversy since the current process allows
> the normative version of artifacts to be published in other formats.
> Briefly, I think that's a mistake too. The web is how documents are
> distributed in the modern world and (X)HTML is the lingua franca of
> the web. (The fact that the current process allows the normative
> version of a specification to be published in *both* (X)HTML and PDF
> is totally unacceptable as it will eventually result in two putatively
> normative specifications that do not agree with each other.)
> 
> As to the URI used for these specifications, I think it would be
> sufficent to use the short, administrator approved, product name to
> construct the URI as follows:
> 
>   http://docs.oasis-open.org/name-of-tc/name-of-product/
> 
> The administrator can make sure that no product name is ever reused by
> a single TC. I think it would make sense if the URI above identified
> the "current version" of the product specification. It would also make
> sense to publish a dated URI as well to point to specific versions:
> 
>   http://docs.oasis-open.org/name-of-tc/name-of-product-YYYY-MM-DD/
> 
> As to the naming of various other artifacts associated with the
> product (schemas, images, stylesheets, etc.), I think it's probably
> sufficient to say that every one of them must be reachable (at least
> indirectly) through links from the normative specification.
> 
> I hope that these comments are helpful and I do regret that these
> comments are probably quite radically different from what you had
> expected. I think if you'd done more of the work on this document in
> public, it would have been possible to make these suggestions earlier
> when it might have been less difficult to make the necessary changes.
> 
>                                         Be seeing you,
>                                           norm
> 
> [1] http://norman.walsh.name/2004/03/03/266NorthPleasant
> 
> 

--