[sc34wg3] Questions on N0396: (5) topic item (other computed values?)

[Lars Marius Garshol]

* Jan Algermissen
|
| In a topic item, there is no property that provides the
| information 
| 
| a) of what associations the topic is a type
| 
| b) of what association roles the topic is a type
| 
| Is it correct that a conforming implementation does not need
| to provide that information?
 
Yes and no. You can find out which associations a topic is a type of
by traversing all association items in the topic map. So the
information is required to be there, but there is no requirement that
it be provided in a form that is convenient or efficient to access.
 
| If so, I think it would make a lot of sense to include two optional
| properties in N0396 that can provide that information.  

I wouldn't say that it *doesn't* make sense, but I can see several
reasons not to do it:

 a) it means complicating the model by introducing optional
    properties, 

 b) it complicates the model by introducing more properties,

 c) you have to decide where to stop, (occurrence types? themes? topic
    name themes as distinct from occurrence themes? all role types
    played by the topic? properties with all topic / topic name /
    occurrence / ... types on the topic map item?), 

 d) the information is redundant, and

 e) we would suddenly start making specific requirements on the form
    in which topic maps are made available to the applicatiom, which
    we don't do now.

| N0396 could also constrain implementations that do choose to provide
| that information, to do it in exactly this way. This would propagate
| all the way to the API level and would make implementations much
| more interoperable, while preserving the freedom to exclude the
| information (e.g. for efficiency reasons).

It would, but I'm not sure it would give us any more interoperability.
You can (in fact, almost certainly would) still have APIs that are
sufficiently different that you would need different code to work with
different implementations.

API-level interoperability does make sense, but the only way to
achieve it would be to actually make a standard API. I think probably
we should do that at some stage, and this would make sense there.

Oh, BTW: Thanks a lot for doing this SAM review. Good questions.

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