[sc34wg3] SAM 3.4.4 Reification and 3.4.5 Properties

[Lars Marius Garshol]

* Luis J. Martinez
| 
| I understand that subjects are in a different layer of abstraction
| than the topic maps items and are already represented by topic
| items. But, the SAM is responsible to describe how to manage
| subjects for merging. That functionality is part of SAM, therefor
| subjects probably should be treated as first class objects under the
| SAM framework.

That would mean treating names, relationships, and so on as first
class objects as well. I'm not sure what we would achieve by that.
I suppose what I am asking for is what you think is unclear today that
would be clearer if we did this.
 
* Lars Marius Garshol
|
| That's not to say that your suggestion is wholly wrong. I think for
| a conceptual model that would make sense, but the SAM is a data
| model designed to support interoperability (XTM/HyTM/CXTM) and the
| definition of query and constraint languages.
 
* Luis J. Martinez
|
| This exact point is one that I don't completely get. The SAM looks
| to me like a implementation design document, very detail. Why does
| the SAM has to be so specific? Should this model leave the details
| up to implementation, like the locator items?

This is something that has confused many people, but I'm not sure
why. I'd like to change it, if I could. You have to take the
conformance section into account when reading the SAM. As that says,
so long as you can explain how your internal model maps to SAM, detect
errors, and merge correctly, you conform to the SAM.

However, I've been wondering whether we shouldn't restate the whole
conformance section as something like this:

  "Conformance to this model is not a goal. This model is only used as
  a basis for other normative specifications, and it is these
  implementations will either conform or not conform to."

I'm not sure we really care if people conform to the SAM. What we want
is for them to conform to XTM, HyTM, TMCL, and TMQL. What they do
internally is really their own business, and if we want to standardize
that we should do it by creating a standard API instead.

This is what I've been thinking, but as you can see it's not in the
document. Reactions to this would be very welcome.
 
| I am realizing that what I am looking for if the description of the
| application semantics of Topic Maps. I think that the RM/TMM is more
| abstract and the SAM is very low level, almost an API. So, is there
| something missing in between?

I think SAM provides the application semantics. What semantics is it
you would like to see that aren't there?

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