RE: [xri] Metadata I1 - Identifier Type

["Wachob, Gabe" <gwachob@visa.com>]

It would seem to me that if NAC is an area-specialist, then they should
be the forum for defining area-specific types. As an analogy, we didn't
say that we were going to define all the language tags under $l - we
referred to an external specification for language codes. 

We can accommodate this sort of delegation of specification through XRI
authority delegation. We could simply let NAC have @nac and let NAC
define name under @nac. They could also specify use cases for @nac in
cross references such as defining "type" for a subsegment. And this
could be done on *NAC*'s timeframe, not the TC's. 

Would this satisfy the NAC requirements? I'm still not convinced we need
to define something in the metadata ($ namespace) spec. 

	-Gabe 

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> Sent: Monday, September 12, 2005 5:02 PM
> To: Lindelsee, Mike ; xri@lists.oasis-open.org
> Subject: RE: [xri] Metadata I1 - Identifier Type
> 
> [Apoligies in advance - it appears my backed-up emails 
> arrived in reverse
> thread order, so I got to this last.]
> 
> Mike,
> 
> The scope of the XRI Metadata spec is, to quote from section 
> 1.1, Purpose of
> this Specification:
> 
> "The purpose of this specification is to define a set of XRIs in the $
> namespace that function as identifier metadata - attributes 
> that may be used
> describe an identifier itself, as opposed to attributes of 
> the resource it
> identifies."
> 
> The proposal from Boeing is for the XRI TC to work with the Network
> Applications Consortium Identifier Semantics Workgroup to do 
> just that:
> define metadata that used to describe an identifier itself - 
> in this case,
> its type.
> 
> My understanding is that there are approximately a dozen types of
> identifiers widely used in enterprise infrastructure that 
> would fall under
> this requirement. The NAC is willing to work with the TC to 
> help define
> these.
> 
> This strikes me as precisely what we intended the Metadata 
> specification
> for. What am I missing?
> 
> =Drummond 
> 
> -----Original Message-----
> From: Lindelsee, Mike [mailto:mlindels@visa.com] 
> Sent: Monday, September 12, 2005 4:02 PM
> To: xri@lists.oasis-open.org
> Subject: RE: [xri] Metadata I1 - Identifier Type
> 
> While the motivation is sound -- having an ambiguous tag 
> would be a real
> problem -- I'm concerned about the scope of this issue.  I 
> don't see it
> as part of the XRI TC's charter to be normatively defining tags for
> things.  There are a host of other bodies that are working on 
> this sort
> of thing (Dublin Core comes to mind).  Can we just refer to the
> appropriate specifications instead of actually specifying new tags?  I
> think that would be well within our charter.
> 
> Mike 
> 
> >-----Original Message-----
> >From: Dave McAlpin [mailto:Dave.McAlpin@epok.net] 
> >Sent: Monday, September 12, 2005 3:48 PM
> >To: Lindelsee, Mike ; xri@lists.oasis-open.org
> >Subject: RE: [xri] Metadata I1 - Identifier Type
> >
> >The idea is that there should be a standardized, canonical
> >representation of various common identifier types - a standard way to
> >represent something like an employee number in an XRI, for 
> example. The
> >+ namespace isn't sufficient for this because there's no authority to
> >give it an official definition.
> >
> >The request, which came from external parties, is that the TC publish
> >these canonical representations to promote interoperability. They've
> >volunteered to most of the work on putting these together.
> >
> >Dave
> >
> >> -----Original Message-----
> >> From: Lindelsee, Mike [mailto:mlindels@visa.com]
> >> Sent: Monday, September 12, 2005 3:01 PM
> >> To: xri@lists.oasis-open.org
> >> Subject: [xri] Metadata I1 - Identifier Type
> >> 
> >> I thought I'd start a round of discussion on the various issues.  I
> >> noted that this issue doesn't have a proposal page yet.  
> I'd request
> >> that we start with a list of requirements instead of 
> jumping straight
> >to
> >> solutions.  That way we will all be able to understand if 
> a solution
> >is
> >> sufficient and if those requirements are requirements that 
> >the TC as a
> >> whole feels need to be met (or can be met in other ways).
> >> 
> >> My initial thought is that identifiers/segments/subsegments 
> >can easily
> >> be identified by using the + namespace.  I don't see any 
> reason that
> >new
> >> text would need to be added to the spec(s) to support this 
> >capability.
> >> 
> >> Mike
> >> 
> >> 
> ---------------------------------------------------------------------
> >> 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_workg
> roups.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_workgr
> oups.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_workgr
> oups.php 
> 
>