[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 438-450): 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. Thanks. 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 the >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 -- see >the XRI Metadata Specification V2 Committee Draft 01, >http://www.oasis-open.org/committees/download.php/11854/xri-metadata-V2.0-cd >-01.pdf). > >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 team and >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 >================ >Drummond Reed >Co-Chair, OASIS XRI & XDI TCs >http://public.xdi.org/=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 >goes: > >Proposal: >Withdraw the working draft; rethink requirements for identification and >addressing as distinct issues. > >Reason: >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. > >Argument: >There is little disagreement that it is useful to identify any given >artifact. Giving it identity allows for the artifact to be cited, referenced >and talked about in a manner such that there is no ambiguity as to its >nature. >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 contextual >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 redirection >a specific conformance requirement to send a user from an "abstract" URI >representing a particular artifact to a "concrete" network endpoint resource >(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 >associative. > >Some examples: >I can talk about a "work" (for example a TC's charter, an information model, >a specification) as well as representations of that work (the charter as >first published; a revision to the charter;version 5 of a particular schema; >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 the >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 and >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 such >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 OASIS >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > >--------------------------------------------------------------------- >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 >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]