OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oasis-member-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [oasis-member-discuss] Comments on Artifact ID requirements

Peter, Drummond, Dave, and Gabe -

The OASIS Technical Advisory Board Quality Subcommittee (QSC) would like to set up a phone meeting with at least some of you to discuss the application and relevance of XRI to out ongoing Artifact Identification Requirements and included metadata in XHTML/HTML artifacts.

Our next QSC meeting is October 14 2005 from 11:00am US Eastern time. Is there a time in that meeting that you could join us for perhaps 45 minutes?

I know that at least one of you is on CET, and I don't know your other timezones. If other times would be preferable, please let me know and I'll work the the QSC to arrange. 

I will provide a caller-paid conference number.


bill cox

+1 862 485 3696 cell

Peter F Brown wrote:
Any news or follow up on this?


Peter F Brown

Senior Expert
ICT-Strategy Unit
Austrian Federal Chancellery
Chair, CEN eGovernment Focus Group
T: +43.1.53115.6161
W: www.cio.gv.at

No trees were cut down in the production of this message; many electrons
were however severely agitated

-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: 12 August 2005 21:42
To: 'William Cox'
Cc: peter@justbrown.net; oasis-member-discuss@lists.oasis-open.org; 'Wachob,
Gabe'; 'Dave McAlpin'; mary.mcrae@oasis-open.org; 'James Bryce Clark'
Subject: RE: [oasis-member-discuss] Comments on Artifact ID requirements


Thanks much for the offer. I just sent Jamie and Mary another note on a
different topic that underscores why OASIS should look closely at XRI for
its artifact identification.

My biggest challenge right now is bandwidth - I'm booked pretty heavily for
the next two weeks, although Thursday the 25th and the morning of Friday the
26th are possiblities. Starting the week after that it gets better.

For the XRI TC's part I'm volunteering my co-chair Gabe Wachob and XRI
Editor's Subcommittee chair Dave McAlpin (who I know is on vacation this

So my recommendation would be to schedule a call about two weeks out and see
who can make it at that time.

I look forward to the discussion.



-----Original Message-----
From: William Cox [mailto:wtcox@comcast.net]
Sent: Friday, August 12, 2005 9:44 AM
To: Drummond Reed
Cc: peter@justbrown.net; oasis-member-discuss@lists.oasis-open.org; 'Wachob,
Gabe'; 'Dave McAlpin'; mary.mcrae@oasis-open.org; 'James Bryce Clark'
Subject: Re: [oasis-member-discuss] Comments on Artifact ID requirements

Drummond -

I'm interested in such a discussion; I will also volunteer Mary (subject to
Jamie and Mary's veto).

Per the Member Review AIR WD 15.pdf document distributed with AIR WD15,

"7. This document specifies a set of Required Metadata for OASIS artifacts
to be available in the document and/or associated metadata, and also as a
basis for exposing selected metadata in the Artifact Identifier. Comments
would be appreciated on the following plan for XHTML metadata in the next
Working Draft, and would be inserted into section 5.5.2 and 5.5.3 (lines

Use the style of "Expressing Dublin Core in HTML/XHTML meta and link
elements," Dublin Core Metadata Initiative Recommendation, November 30,
2003, http://dublincore.org/documents/dcq-html/. The intent is to follow the
style, but not to make normative reference to the Recommendation There will
be one meta element per name-value pair. We may need to define an OASIS
metadata namespace to use as a prefix for the metadata names.
The compatibility for versions of HTML before XHTML 1.0 would parallel that
for the DCMI Recommendation."

Your proposed discussion addresses closely related issues.

When can we get together? This strikes me as a phone discussion at first.


bill cox

Drummond Reed wrote:

Although I just returned from an extended vacation (and must admit that 
I have not had time to review the Artifact ID requirements in depth 
yet), nonetheless the points Peter makes in this message are very good 
ones, and in fact are central to XRI (Extensible Resource Identifiers) 
specifications developed by the XRI TC 
(http://www.oasis-open.org/committees/xri). XRIs extend (and are 
backwards compatible with) URI/IRI syntax and add features designed 
explicitly for abstract identification of resources -- and resolution 
into concrete representations of those resources -- following
precise guidelines Peter describes.

A further benefit is that XRIs standardize several of the key types of 
identifier metadata Peter enumerates (such as version, language, date 
the XRI Metadata Specification V2 Committee Draft 01, 

Lastly, the XRI 2.0 specifications include full support for HTTP proxy 
resolution so all XRI syntax and resolution capabilities can be 
deployed immediately using available HTTP infrastructure.

A suggestion, then, is to arrange a meeting between the Artifact ID 
the XRI TC to discuss the requirements and see if XRI 2.0 can help 
OASIS solve its resource identification needs.

Mary, Jamie - who should we contact about this?

Drummond Reed

-----Original Message-----
From: Peter F Brown [mailto:peter@justbrown.net] 
Sent: Tuesday, August 02, 2005 4:53 AM
To: oasis-member-discuss@lists.oasis-open.org
Subject: [oasis-member-discuss] Comments on Artifact ID requirements

Dear all:

Whilst I appreciate that much effort and time has gone in to this draft
recommendation, I am very uncomfortable with the proposals as they stand. I
have only just had an opportunity to look the document through and compose
some comments: possibly too little and too late.

The TAB asks that comments and proposals be specific and concrete, so here

Withdraw the working draft; rethink requirements for identification and
addressing as distinct issues.

There is a fundamental conceptual flaw in the proposals, and one which we
unfortunately see all too often on the web, and is perpetuated by a similar
conceptual flaw in the W3C's own thinking on the issue.

This flaw is to confuse the identity and the address of an artifact,
ultimately concluding that they are the same. The consequence of this flaw
would be that the proposals, if applied, would irretrievably confuse and
combine two important concepts that require to be considered as distinct in
any coherent and lasting information architecture.

There is little disagreement that it is useful to identify any given
artifact. Giving it identity allows for the artifact to be cited,
and talked about in a manner such that there is no ambiguity as to its
Ambiguity can enter the picture, however, from the moment that an artifact
is considered in a particular context: which version of the artifact? Which
format? In which language? In sum, which "representation" [1]? The reality
is that every combination of such factors (language, format, version, etc.)
leads to a specific and unique artifact: sometimes it is useful to identify
and reference such specific representations; other times it is more useful
to reference and identify the "abstract" entity.

The objective of the proposed requirements is essentailly to be able to
reference, cite and link to only representations and not abstract entities,
but there are two steps to such an approach which are unfortunately rolled
into a single issue in the proposal:
- firstly it is necessary to identify an artifact: to be sure that we are
talking about the same "thing";
- secondly, it is necessary to dereference that identity *in context*.
It is this second step that is often so unstable because too many
issues are left implicit in the process of resolution (naming > addressing)
whereas they should be made explicit.
This is implicit in the proposal as it calls on TCs to even make
a specific conformance requirement to send a user from an "abstract" URI
representing a particular artifact to a "concrete" network endpoint
(or "representation").

There is currently no generally accepted distinction between a conceptual
"entity" and a "real" artifact which, I beleive, is not only useful but
essential to disambiguate the issues related to identification and
representation addressing.*

The structure of the proposed identifier explicitly admits that semantics
can be deduced from the ID. These semantics - such as "version", "stage",
etc. refer to aspects of a work's process lifecycle and not to inherent and
non-dissociable properties of the work itself.

The identifier structure also implies a hierarchical relationship between
components of the identifier, whereas the relationship is purely

Some examples:
I can talk about a "work" (for example a TC's charter, an information
a specification) as well as representations of that work (the charter as
first published; a revision to the charter;version 5 of a particular
the French language translation of the current version of a specification).
The current proposal makes no distinction between the conceptual, abstract
entity and its representations.

A document does not "have" a "version": version is a property of a
relationship between an abstract entity and a representation, it is not an
inherent property of the representation itself. The representation does not
change (hence, consistent with the principle of permanent URLs) but only
nature of its relationships through associations.

Ultimately, any persistent referencing architecture should only use the
identity of an abstract entity which should be de-referenced dynamically
contextually to then point and direct to a specific concrete entity. One of
the greatest sources of "broken link" problems is precisely the lack of
information architectural modeling.

Any attempt to establish an addressing model that relies upon and is based
on context-dependent links will ultimately fail and is not sustainable. It
is far more stable and dependable to build artifact identity based on the
conceptual layer.

[1] "Representation" - a specific rendition of a given "abstract" or
conceptual artifact

Peter F Brown
Chair, CEN eGovernment Focus Group
ICT-Strategy Unit
Austrian Federal Chancellery
Co-Editor, OASIS SOA Reference Model

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in



To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]