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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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


Subject: Re: ebxml identifiers


> Jon:

Thank you for the comments.  I expected a barrage of comments on that posting but so far
you are the only one.  Some more comment interspersed throguhout the email


> <duane>| It has been suggested that we use a unique ID which is
> | semantically meaningful to at least one person on the planet.  The
> | logic there is while no one can define a key which is universally
> | acceptable but at least some will be able to make use of it.</duane>
>

<jon>I am among those holding the opinion that labels meaningful to someone are better
than labels meaningful to no one.  The utilitarian calculus on this is pretty simple; if U
is the utility

> to an individual of being able to use a mnemonically significant
> set of terms and N is the number of people for whom a set of terms
> in mnemonically significant, then
>
>    U * N > U * 0</jon>

There is also the Duane train of thought which also recognizes that anytime you have an
issue where people must determine the right to use names for a unique URI,  the amount of
time to complete the damn thing is invesly proportionate to the number of people
expressing an opinion.  Therefore,  given the timeframe for ebXML, it may be in the best
interest to go with a meaningless UID key for the machine querying.

What I am suggesting is a way which would meet the full funtionality and allow individuals
to query for their own meangingful keys.  Imagine the following represents a data element
in a repository.  It is for a vegetable that gets used by lots of different people:

<item>
  <IUD>hfjd44JS</UID>
  <!-- this is the key that is for the machine to query on-->
  <equivalent_to>
     <name>Tomato</name>
     <owner>an american person</owner>
  </equivalent_to>
    <equivalent_to>
     <name>Tomahto</name>
     <owner>an british person</owner>
  </equivalent_to>
   <equivalent_to>
     <name>Red thing - eh</name>
     <owner>an Canadian person</owner>
  </equivalent_to>
</item>

The machine would always search for the unique key while the individuals could then use
semantically meaningful query terms to locate items based on what they want.

> <jon>
> The assumption here is that the use of *any* meaningful labels
> would entail "the political upheaval of EDI vs. other standards".
> I'm not seeing any reasoning here to establish that the one thing
> would follow from the other.</jon>

This will more than likely happen and even if it doesn;t,  it will be perceived as
happening.  Imagine that EDIFACT gets all the english words reserved for their own items
in an ebXML common data element business repository.    Personally,  I wouldn't care
because I would know that those are no more meaningful OR meaningless at query time to
another application.  However,  I could (but won't) name dozens of  people who would start
a holy war.  ;-)

> | Secondly, the unique key is for a Machine to find only, not a
> | human.
>
> I see no support for this assertion.  On general principles I find
> highly doubtful the proposition that no human being will find
> mnemonic labels useful.  At the very least, we humans engaged in
> defining the set of labels will find mnemonic qualities useful.
> This is particularly true in the case of names for low-level data
> elements.

I have to apologize for maybe not fully describing what I had in mind.  The semantically
meaningless key is only one of many that can be searched on.  it is just a way to
guarantee that we have at least one completely unique key for each rep item.  We can still
allow others to have multiple semantically meaningful keys so I can search for the "red
thing" and you can query for "tomato".  That way everybody is appeased, the applications
are happy,  there are no collisions of identifiers and people can still associate
meaningful words with repository items.

Thank you for the comments Jon.

Duane




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


Powered by eList eXpress LLC