[sc34wg3] occurrence - basename fuzzy boarder

[Nikita Ogievetsky]

Lars:
> * Bernard Vatant
> |
> | Now that TNC is relaxed and typing of names is allowed, the (already
> | fuzzy) boarder between names and occurrences seems to fade away a
> | little more. 
> |
> | And well, that's good news for those who have always considered this
> | boarder to be a syntactic answer to a non-question :) 
> 
> I agree that this change is likely to make people ask what the
> distinction is supposed to be. The SAM answers that question as
> follows:
> 
>   "A base name is a name or label for a subject, expressed as a
>   string. That is, it is something that identifies the subject (though
>   not necessarily uniquely) and can be used as a label for the subject
>   in user interfaces. The notion of a base name corresponds closely to
>   the common sense notion of a name. Suitable base names for people,
>   countries, and organizations are their names, while base names for
>   documents, musical works, and movies might be their titles. Base
>   names may have variant names, which are alternative forms of the
>   base name that may be more appropriate in specific contexts."
> 
>   "An occurrence is a relationship between a subject and an
>   information resource. The precise nature of this relationship is
>   described by the occurrence type, a subject which is attached to the
>   occurrence. Occurrences are generally used to attach information
>   resources to the subjects they are relevant to. Note that the
>   occurrence is properly not the resource, but the relationship
>   between it and the subject. The information resource may either be a
>   string inside the topic map or an external information resource."
> 
> That gives us something of a line between the two, doesn't it?

Absolutely
 
> | Let's say occurrences and basenames together form a class of
> | "information items". We can define at least two clear orthogonal
> | subclasses - orthogonal to each other, more clearly defined than,
> | and orthogonal to, the fuzzy name-occurrence classification.
> 
> Actually, this is the way it has been seen for a long time, that
> occurrences are a specialization of associations, and that base names
> are a specialization of occurrences. The SAM does not express this
> since we didn't want to encumber it with the notion of subclassing,
> but we could still make this explicit in the prose.
> 
> The conceptual model for TMs in XTM doesn't make this clear, which I
> think it ought to have done.

RM does.
  
> | 1. Identifier vs Non-identifier
> | Some types of names (e.g. codes) will be used as unique identifiers,
> | and some will not.  Some types of occurrences could also be used as
> | unique identifiers (think about biometric identifiers,
> | e.g. fingerprints), and some should not.  And it figures: where is
> | the boarder between this name-occurrence superclass and subject
> | indicators for that matter?
> 
> It's a good question. You can see subject indicators as an unscopeable
> occurrence type, and the same for subject addresses. This train of
> thought, if followed to the end essentially leads to RDF, or variants
> thereof, such as the RM. I've been down this road many times myself,
> but always come to the conclusion that the distinctions made in the
> current topic map model are actually very helpful for human beings,
> and sometimes also for machines.
> 
> If you think differently of this I'd love to hear why.

I agree with this but by letting "unambiguous" PSI 
to type occurrences as well as base names we got closer to opening
a Pandora Box.

 
> | 2. Internal vs External
> | There is more difference between an external occurrence of type
> | e.g. "Home Page" defined by a <resourceRef> link and an internal
> | occurrence of type "Short Description" defined by a <resourceData>,
> | than between the same "Short Description" and some basename of type
> | "Long Name".
> 
> That's true structurally, but not semantically.

Well, now one should use "Short Description"  baseName type
not occurrence type. It is just that "baseName" is a confusing
term.


Nikita Ogievetsky, nogievet@cogx.com;
Cogitech Inc.        http://www.cogx.com   
Topic Maps Tutorials and Consultanting. 
phone:  1 (917) 406 - 8734