[topicmapmail] From RM to DM

Thu, 18 Dec 2003 16:21:17 -0800

| Do you plan to implement something RM-based?

I'm doing prototypes now for implementing controlled vocabularies (thesauri
& indexes) plus general metadata using a triple-store (RDF).  

Thanks for the scope example. I didn't understand that SIDPs are abstract
(or has a merging-interface), not just subjectIndicator or subjectLocator
(that's SAM-speak).

What if I wanted to reify an ( I think this is a dated term) association
template -- this would be a higher-order subject, or a subject about a
schema contraint. That way I could talk about all the instances of a class
of assertions -- oh, that would be the t-topic, no?

So, if I wanted to I could implement my names-as-subjects (the literals I
was talking about) not as SIDPs but as OPs, but then they wouldn't be
accessable for merging -- effectively turning off the "topic naming
contraint"... but then I couldn't have variant-names, because the names
aren't subjects and therefore able to be reified and used as role-players in
an assertion...

- Jason

| -----Original Message-----
| From: Jan Algermissen [mailto:jalgermissen@topicmapping.com]
| Sent: Thursday, December 18, 2003 11:04 AM
| To: Jason Cupp
| Cc: Topicmapmail
| Subject: Re: [topicmapmail] From RM to DM
| 
| 
| 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