[sc34wg3] Re: integrating all TMAs

[Jan Algermissen]

Steve Pepper wrote:

> OK. Then I think I understand a lot more. In a sense,
> what the RM is saying is:

[...]

> * The SAM is a specialization of this model that
>    subclasses assertions as associations, occurrences,
>    names and variants (and permits a special kind of
>    assertion - called scope - to be made about those
>    assertions).
> 

The RM provides the ground for defining the SAM, it provides
a way to argue about certain design decisions made by the SAM,
and it provides a way to better understand the effects that
certain decisions will have in the future. Written as a TMA
according to the definitorial requirements of the RM the SAM
will (among other things) include:

Properties:

Two core properties are 'SubjectAddress' (value type 'Locator')
and SubjectIndicators (value type: 'SetOfLocators'). Both 
are SIDPs, meaning that they are properties that provide a way
decide whether two topics surrogate the same subject and should
be merged.

Assertion Types:

The SAM must include assertion types that provide the semantics
of the relationship between topics and names, topics and occurrences,
classes and instances etc. In other words, some of the infoset properties
in the current SAM would become assertion types in the RM-defined SAM.
[Don't panic! This does not require SAM implementations to actually implement
the assertions in their full glory ("the nodes and arcs")]

[I assure you that, supposed we reach consensus and the SAM is done in RM terms,
 the hot arguments will not be in this corner, all this is propably more
 a matter of wording and gaining more understanding (on both sides)]

Merging rules:

The merging rules will say, solely based on SIDP values, when two topics
are to be merged or not.

Example: "When two topics exhibit the same value for the SubjectAddress
          property they are to be merged" ('same' to be defined of course)


Scope is among the hot issues. My personal understanding of scope
has allways been extremely different from at least Lars' and Kal's
understanding. To me a scope has allways been a subject in it's own
right, to be represented as a single surrogate inside an implementation,
while Ontopia's software [1] and TM4J 'demonstrate' a different understanding:
Both APIs allow to get the set of topics that 'are scoping' it, but there
is no way to get something that *is* the scope, there is no getAllScopes()
method.

Both ways have advantages and disadvantages, the RM allows the SAM to
choose either one and the eventual decision will be based on verious
considerations. I am going into these details here, because I want to
emphasize that the RM allows us to actually discuss these things on a
formal basis. [2]

There is much more to say and to clarify (I think), but there
is other work waiting, sorry.

Jan

P.S.

Just one more time, to make sure this is clear: The RM is not
affecting the SAM as much as most people think. The
RM would require some conceptual changes on the SAM, but they
are propably only beneficial for everybody.

I beg (PLEASE!) let's not have the argument if we will do the SAM
in RM terms, let's save our breath for arguing about the different
understandings ABOUT the SAM. This will be a productive task, in which
both sides can learn (and communicate on a formal basis).


[1] At the time I beta-tested it, back in 2001.

[2] Bottom line for the scope issue: Will the SAM recognize scope
    as a subject (leading to assertions of type 'at-scope-assertion'
    to represent scoping) or will the SAM define scope as a property
    (value type: set of topics)

--
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org