[sc34wg3] occurrence - basename fuzzy border

Lars Marius Garshol sc34wg3@isotopicmaps.org
23 Feb 2003 23:20:54 +0100

* Nikita Ogievetsky
| I do not like variants at all. There was no apparent need to put
| them on baseNames.

Yes and no. We don't really need anything more than topics and
associations, but topic maps are really about hitting the 80/20 spot,
and I think variants are on the right side of that line. They are
close, admittedly, but still on the right side, IMHO.

| (You may say sorting and display... well it could have been done
| differently, i.e. through reification, etc. as Steve had mentioned)
| .


| However if they are there and if baseName assertion is just a
| special case of more general occurrences assertion then why the
| asymmetry? 

One reason is structural: base names are always inline strings,
whereas occurrences may be external resources.

| Variants on occurrences might have been just as useful.  For example
| they might be used to indicate different ways to access a resource
| depending on the device context, protocol, location, etc.

I agree. The question is how often we need that, weighed against the
cost of the change. I'd be very interested to hear from people who
have come across this need in real life?
| As I had mentioned in Baltimore, variants provide for the only
| difference between occurrence and baseName elements.
| Especially now when we had introduced instanceOf child elements on
| baseNames.

There's still the inline/external difference. 
| Allowing variants on occurrences will make content model more
| uniform and it will still be backward compatible.

Uniformity of content models is a goal, admittedly, but I am not sure
that occurrence variants will be using the same element type and the
same information item type. We'd either generalize the variant concept
further, or distinguish occurrence variants from name variants.
| I do not see how it would add complexity? It will definitely be more
| readable then reified occurrences!

It increases the complexity of the model, so there is a cost for
implementors and also for the query language and constraint language,
as well as the syntaxes (HyTM, XTM, LTM, AsTMa=).

| (not that I would use it :-))

In that case, why should we accept the added complexity?

Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >