[topicmapmail] From RM to DM

[Jan Algermissen]

Jason--

good questions!


Jason Cupp wrote:
> 
> The RM has no mention of Data Model things like occurrences, scope, names,
> variants, etc... only assertions and sub-graphs of the assertion graph that
> are targets for reification in the n-ary relationship model: t-topics,
> c-topics, r-topics, x-topics, a-topics.

The RM operates at a lower level than the SAM. Since occurrences, names,
variants etc are essentially all just relationships between subjects,
assertions are sufficient to represent all of them. The Standard Application
Model (SAM) is then simple the appropriate set of assertions types and properties.

The goal of the RM is to enable the definition of such 'sets of semantics' as
the SAM (in the current RM version, such a definition is coined as 'Disclosure')
> 
> But if I'm implementing the DM using the new RM, do I have to do the
> following things????

In general, the RM doe in no way constrain an application, the only thing
you have to do is to document (and thus make explixit) how your application
maps to the RM. For example, the a-sidp property might well be hidden in
a certain method on objects of a certain class.

> 
> 1) reify every name and occurrence resourceData, they become x-topics in
> assertions for relating <topic, name>, <name, variant>, and <topic,
> occurrence>. But reifying literal strings gives me a new reification
> operator "subjectLiteral", along with subjectLocator, subjectIndicator?

First let me say that it is really great that you understood (or are very
close to understandig) the essence of the RM - believe me, I know that it takes
some effort to make the neccessary mind-shift.

To answer your question: 

(Note that 'reification' has a different meaning in the SAM world than in the
RM world. In the RM understanding, 'to reify' means to provide a surrogate
(topic (RM-sense)) for a subject. So the question if you want to reify certain
subjects is a matter of your needs: if you want to make statements about certain
subjects, you need to reify them otherwise not.

There are a lot of implications behind such a decision, especially concerning the
power the Application (the Disclosure) you define will have. If you want, I'll
go into details on this - please let me know.

A remark: In my personal opinion the current SAM draft really falls short of the
power it could have, because certain subjects are NOT reified (RM-sense!) which
in turn limits the degree of, hmmm, 'information interconnection'.

OTH, one of the purposes of the RM is to provide a means for investigating and
discussion these decisions and their implications, so people have a sound basis
to judge the quality of an Application ('Disclosure').

Bottom line: you can pretty much do what you like (you can also make everything
(occurrences,names,etc.) a property) but you need to document what you do, thus
maximizing the interchangeability of your topic maps.

> 
> 2) does DM scope then become the total of all the other assertions (those
> not included in the DM) made about these other assertions: a) <topic,name>,
> b) <name, variant>, c) <topic, occurrence>, d) <a-topic, c-topic, c-topic,
> ...)

Here are two completely different, yet possible ways to do scope in terms of
the RM:

1) Scope as a property, consisting of a set of topics

- define a property in your Application/Disclosure that has a value type
  'set of topics'. Let's call this property 'ScopingTopics'. It is an OP
  (other property) because it does not serve as a basis for merging.

- in your systax processing model, define how, for example, XTM's <scope>
  element and children are to be processed and that the set of topics that
  make up the scope are to be assigned as the value to the 'ScopingTopics'
  property of topics that surrogate relationships (<associations>).


Think of the result as

t_a --ScopingTopics--> {t1,t2,t3}

Major advantage of this approach: ease of implementation
Major disadvantage: The scoping set is not reified, so you do not
get the possibility to directly see all scoped relationships from
a given scope (set of topics). This can only be added by a (proprietary!)
indexing mechanism of a certain software.


2) Scope as an assertion between relationships and a subject that is
   a set of topics

- define an assertion type 'at-association-scope' and two roles
   'role-association' and 'role-scope'
- define a property 'SetMembers' that provides the identity for topics
  that surrogate sets of topics. It is an SIDP, because topics with the
  same value for 'SetMembers' must merge (topics that represent the same
  set represent the same subject and therefore must merge).

- have your processing model define the correct way to construct the
  'SetMembers' property and the required assertion(s).

Your result will look like this:




            at-association-scope
                    |
 role-association   |   role-scope
             |      |      |
             |      |      |
    t_a------C------A------C------x_s[SetMembers={t1,t2,t3}]


(where t_a is (as above) the topic that represents a given relationship
and x_s is the topic that represents the set of topics that is the scope).

Major advantage:  all other relationships that x_s is a scope of will be
connected to x_s in the same way, so you can directly see from x_s all
the relationships it scopes. (e.g. to anser the question: "What are all
occurrences in scpe {t1,t2,t3}). With this approach, this information
is directly available, no propriatry indexing mechanisms are needed
(meaning that no matter what SAM-conformant sofware you use, you'll
allways have that information, likely also in the API then with some
scope.getAllScopedAssociations() method.
Major disadvantage: Topic Map (in store) increases in size 

But again, this is a matter of taste and desired power of your Application.


> Just curious... jason

You are welcome! Do you plan to implement something RM-based? I'd be
happy to give you any information you need.

Jan


> 
> _______________________________________________
> topicmapmail mailing list
> topicmapmail@infoloom.com
> http://www.infoloom.com/mailman/listinfo/topicmapmail

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