On ID "sameness"

[Tony Linde]

I still prefer an ID for any resource to be unique. I was thinking more
along the lines of a unique ID and some other field, like Reagan's
'semantic ID' being used for making two resources the 'same' (needs some
sort of naming standards).Then you have other fields to identify other
relationships. That said, I guess if we make the ID a semantic one, we
could have another 'Unique ID' field to uniquely identify a specific
resource.

Why do we need a unique ID? If you want to identify exactly which
resource was used - foir rerunning, debugging, etc. You might use the
semantic ID plus location identifier, but what if a location has six
copies of the same resource?

Cheers,
Tony.

On Wed, 5 Feb 2003 02:48:30 -0600 (CST), "Ray Plante"
<rplante at poplar.ncsa.uiuc.edu> said:
> Hi,
> 
> We still have this issue of "sameness": that is, when should two
> instances of an object be consider the same, and thus be refered to by
> the same identifier?  Reagan brought up the concept of a "semantic
> copies", copies that are semantically the same but might have a
> different byte-representation.  Tom indicated what might be considered
> semantically equivalent might depend on the context; he suggested that
> we should leave it up to the user to decide when objects are the same
> rather than locking it in up front.  
> 
> Drawing on ideas presented earlier by others, I'd like to recommend
> the following principles on defining "sameness".  They draw on the
> requirements discussed in my previous message.
> 
> 1. Two identifiers refer to the same thing when the identifiers are
>    character-for-character identical.
> 
> 2. Two local IDs are identical only when the context of the ID is the
>    same.  Global IDs lock in a specific context, and thus can be
>    compared in an absolute sense.
> 
> 3. A description of a resource, service, or data collection might
>    reference identifiers associated with various aspects of the
>    subject.  Examples might include:
>      *  observation ID
>      *  "derived from" or "mirror of" ID.
>      *  parent collection ID
> 
> 4. When two instances of an object can be considered the same is up to
>    the curating resource and will depend on the object being
>    identified.  Curators should consider the following
>    recommendations:
>      * Two resources can be given the same ID if their
>        descriptions are identical apart from the access point.
>      * Two services can be given the same ID if:
>          o  their descriptions are identical (including the interface
> 	    inputs and outputs) apart from the access point.
> 	 o  the implementaions are identical, or otherwise return
> 	    byte-for-byte output for any given set of inputs.  
>      * Two data collections (i.e. anything that that is
>        byte-instantiatable) can be given the same ID if they are
>        byte-for-byte identical.
>    It may be necessary to establish rules or conventions that control
>    who is allowed to declare a "mirror" of something.  
> 
> 5. Because an identifier can be assigned to a variety of things, be
>    they abstract/virtual (e.g. resource IDs, observation IDs) or real
>    byte-instantiatable (e.g. collection IDs), services that
>    specify an ID as part of input or output should be very clear as to
>    what the ID refers to (e.g. an image, a table row, an
>    observation from which a data item is derived, etc.).  
> 
>    In particular with respect to data in a VOTable, it should maximize
>    the reader's options for determining whether two rows are effectively
>    the same for a particular purpose.  This will likely require of
>    definitions of various ID UCDs.  
> 
>    One useful UCD might be one for a "semantic identifier", that
>    refers to another data item that, in the eyes of the writer, a can
>    be considered equivalent to the item being described.  This could
>    be used by the SIA to group images that differ primarily in
>    format.  
> 
> hope this helps,
> Ray
> 
> 
__
Tony Linde                       Phone:  +44 (0)116 223 1292
AstroGrid Project Manager        Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy      Mobile: +44 (0)7753 603356
University of Leicester          Email:  ael at star.le.ac.uk
Leicester, UK   LE1 7RH          Web:    http://www.astrogrid.org

-- 
http://fastmail.fm - IMAP accessible web-mail