TMRM Legends (was Re: Banging the identity drum again, this time REST-style

I was going to come back to this one earlier in the week, but now I'm glad I didn't because I wouldn't have been able to say it so succinctly (and by that, I mean the first paragraph below - the rest is commentary to hopefully illustrate the point).

On 26 Nov 2010, at 6:20 PM, Robert Barta wrote:

> On Tue, Nov 23, 2010 at 02:02:08PM +0100, Lars Heuer wrote:
>> TMRM is atm mainly a wet dream of Topic Maps enthusiast. ;)
> 
> That may be true for those few whimiscally whiny Java developers for whom
> every TMQL statement MUST start with the keyword "SELECT".
> 
> For the beautiful, nonchalantly elegant Perl developer path expressions
> are the key to formulate "constraints":
> 
>  [TMRM]: ... A particular map is said to satisfy a constraint, m |== c, if
>        the application of the constraint results in a non-empty map
> 
> And
> 
>  [TMRM]: ... A map legend is a finite set of constraints.
> 
> --
> 
> Slowly, again for obstinately unconvinced:
> 
>  "Huga. Have TMRM path expression, have legend. Huga."

CORE POINT

While I love the path expressions (and use them quite heavily), I think you can actually define a TMRM legend without them, using only a set of properties with fixed semantics that you define in your implementation medium of choice.  The path expressions become useful when you want to define further constraints governing a specific map, but those subsequent constraints are fundamentally expressed in terms of the semantics of the property labels used by any given implementation.

COMMENTARY

My implementation essentially defines a few basic things (constraints, if you will), and then the rest is built on these.

Constraint 1:  You must have a representation of a property which allows you to associate a value with a fixed property key.

Constraint 2:  A collection of properties MAY be given an identifier which subsequently is used to refer the collection as a whole.  This collection is therefore, by definition, a TMRM proxy instance.

Constraint 3:  Property keys MUST be interpreted as proxy identifiers

Constraint 4:  Property values matching expression X MUST be interpreted as literals

Constraint 5:  Property values matching expression Y MUST be interpreted as proxy identifiers


These 5 are enough of a foundation to be useful, but I define a few more for convenience and to tie my implementation more tightly to core Topic Maps concepts:

Constraint 6:  The value of the property key "isa" MUST be interpreted as the player of the role "class" identified by http://www.topicmaps.org/xtm/1.0/core.xtm#class in the class-instance relationship identified by http://www.topicmaps.org/xtm/1.0/core.xtm#class-instance within the scope of the given proxy instance.

If this property is missing, the proxy MUST be treated as an instance of type "topic" (which, in retrospect, was probably a mistake since it's not quite semantically equivalent to http://www.topicmaps.org/xtm/1.0/core.xtm#topic.  Ah, well... live and learn. :)

Constraint 7:  The value of the property key "reifies" MUST be interpreted as a resource from which zero or more property values within the scope of the given proxy instance are derived (where the resource MAY be another proxy instance).

Constraint 8:  The value of the property key "subject-indicator" MUST be interpreted as a resource unambiguously identifying the subject to which the properties within the current scope of the given proxy instance apply (where the resource MAY be another proxy instance).

Given the above, you have the lovely self-recursive basis that is the foundation of the TMRM that you can then use to build anything you want (and actually other systems like Metabase share this characteristic at a core level).  You could even define a constraint type and properties each with subject-indicator references to PSIs describing their semantics to encode the above in terms of the constraints themselves (left as an exercise for the reader).

Here's the real kicker:  once that was done, you could use any physical representation mechanism: XML, procedural programming language constructs, object instances, instances of a specific programming language class, RDF, database table rows or any other serialization format that made sense for a particular application and which, automagically have a well-defined transformation mechanism that can be expressed in terms of the TMRM.

My approach might not be "pure" enough for some people, but I've found it rather useful over the last several years for a wide variety of things. :)

Hopefully this helps, even if it did get longer than intended....

Cheers,

ast
--
Andrew S. Townley <[email protected]>
http://atownley.org