[sc34wg3] occurrence - basename fuzzy boarder

Michel Biezunski sc34wg3@isotopicmaps.org
Thu, 2 Jan 2003 07:12:44 -0500


> * Geir Ove Grønmo
> |
> | IMO occurrences and basenames should have the same structure. This
> | includes occurrences having variants, basenames having type and
> | basenames having locators. Whether they should be separate item types in
> | SAM or not I'm not entirely sure about. Keeping them as two item types
> | is probably ok.
>
> * Martin Bryan
> |
> | I think you probably have to keep them as two item types, if only
> | because the names will need to be displayed before the occurrences
> | are in many applications.

* Lars Marius Garshol

> True, but you can distinguish names from occurrences without
> necessarily having two different item types. We might for example
> create a PSI for the notion of "name", and then say that any name type
> subtyped from this creates a name rather than an occurrence.
>
> Whether we *want* to do this is another matter entirely, of course.

I believe this is where the distinction between "standard model"
and any other model takes place. The notion of name and occurrence
should be clearly and unambiguously defined (as far as this is possible)
in the standard model. The model should be precise enough to allow
common modeling practice in terms of definition of the application
and software interoperability at the level that will guarantee to
the users of the Standard Model that one software package will understand
the notion of "name" in the same way that another.

If we need another understanding of what a name is, then we need
to create another model than the standard one, and it can still be
a topic map model if it's modeled using assertions defined by the
Topic Maps metamodel. All software will not interoperate if they
are based on the standard model, but this time it's OK because
it will be clear from the beginning that interoperability can only
be guaranteed at the user application level with other software
that implement the same model, even if engines that process the
metamodel will still be able to get something from the information.


Michel
===================================
Michel Biezunski
Coolheads Consulting
402 85th Street #5C
Brooklyn, New York 11209
Email:mb@coolheads.com
Web  :http://www.coolheads.com
Voice: (718) 921-0901
==================================