TMQL: are we asking the right questions? (long)

Hi Folks,

Over the last few weeks since the TMQL discussions started, I've been giving a lot of thought to TMQL and how I might be able to implement it in my own software environment.  During the last couple of days, I've managed to pull together a straw-man implementation (just the parser) of the semantics of the spec to see how hard that would be and also to finalize my understanding of the details.

This process has been illuminating as well as making me appreciate how cleverly the TMQL specification fits together and how much work and careful design has gone into it.  Overall, I think it's an excellent specification, even if I think it does have a couple of areas for extension independent of what I'm talking about now.

The biggest result of this exercise brings me to the title of the email:  I think most of the discussion/disagreements/arguments about what's in, what's out, what are the defaults can be dealt with effectively while still maintaining the overall elegance of the specification's approach and, at the same time, actually reducing the implementation complexity of the specification itself.

The questions currently asked are things like:

	Q: what's the interpretation of the isa relationship?
	Q: what's the interpretation of the ako relationship?
	Q: what should the names of the TMDM axes be?
	Q: what should the behavior of the predefined axes be?

The questions I feel we should be asking are:

	Q: what's the minimal basis on which a useful typed graph query language can be based?
	Q: how can I ensure - with a high degree of certainty - that the behavior of the query
	     environment matches my world view?

What follows is analysis and commentary on the above.

Some time back, I made the following statement to the list before I'd really done much with the spec, but just based on the prior discussion and my own understanding of the technology:

On 2 Apr 2011, at 12:55 PM, Andrew S. Townley wrote:

> At this stage, I'd be tempted to say TMQL really should be just TMRM + the path language with a minimal set of predefined axes (as per the TMRM for class-instance and superclass-subclass), and layered above that are a set of proxies defined to support the named axes and mappings for a particular (likely widely adopted) mapping of the TMRM types and properties to proxy types and properties to the TMDM.  However, this mapping extends core TMQL, rather than being a required part of it.
> 
> In this model, TMQL could then be easily adapted and extended from a solid, unified base and many of the arguments about too many or too few axes, what they're called, etc. wouldn't be part of nor would they hold up the draft of a core TMQL specification.  Addressing these issues separately as topic map applications themselves would allow a certain level of "mix and match" customization of TMQL personalities all built on the same foundation and which should play well together using the existing mechanisms defined within CTM for namespace prefixes.

At the time, it was more of a vague notion rather than a strong belief.  This is no longer the case:  it is now something I firmly believe.

Robert's draft shows quite clearly that everything in TMQL can be reduced to potentially typed, directional navigation within a given graph.  Naturally, this is congruent with the TMRM v7 view of the world, but I think this fact is much more powerful than people realize.

I believe that TMQL done right could go a long way to exposing the world *AS* topic maps, not just to it.

Part of this "doing it right" is to put aside the whole TMRM vs. TMDM minefield for a moment and think about topic maps as general graphs constrained by an ontology defining the path steps (properties) available for "moving" around and on which filtering operations can be performed.  Next, think about the navigation operations themselves (forward, backward, outward, inward) as being a set of prefix, infix and postfix operators that can be applied to "navigable" constructs within the map.

Bringing this abstract view back down to a more concrete and practical perspective, each of the inbound and outbound (forward or backward) operators defined as part of the TMQL path expressions consist of two main parts, the operator notation and the operator behavior.

Given that the definition of the shortcuts in TMQL are all defined in terms of TMQL constructs, e.g:

  [C] step        ::= '->' anchor
                  ==> '>>' 'players' anchor

and

  [L] navigation  ::= '/' anchor [ navigation ]
                  ==> '>>' 'characteristics' anchor '>>' 'atomify' [ navigation ]
  [M] navigation  ::= '\' anchor [ navigation ]
                  ==> '<<' 'atomify' '<<' 'characteristics' anchor [ navigation ]

and

  [AA] path-expression      ::= simple-content-1 'iko' simple-content-2
                            ==> 'tm:subclass-of' '('
                                  'tm:subclass' ':' simple-content-1 ','
                                  'tm:superclass' ':' simple-content-2 ')'
  
  [AB] path-expression      ::= simple-content-1 'isa' simple-content-2
                            ==> 'tm:type-instance' '('
                                  'tm:instance' ':' simple-content-1 ','
                                  'tm:type' ':' simple-content-2 ')'

It should be quite clear that this is a transitive equivalence relationship, so, instead of defining the path expressions as "shortcuts" in terms of the fixed TMDM navigation axes, it would make more sense to reverse the process and define the navigation axes themselves in terms of TMQL path expressions applied to a particular ontology and applied as either prefix, infix or postfix operations.

If this definition wasn't done as a context-free grammar but as proxy instances (in whatever your preferred surface syntax happened to be), then you could always ensure your environment behaved as expected.

Additionally, if the navigation operators themselves, e.g. '\', '/', '<<', '>>', '//', etc. were also defined as proxy instances based on a fixed notion of elemental operations (as part of a TMQL bootstrap ontology) that they perform and the byte sequence by which they should be triggered, then a consistent way to express their behavior would be possible.

Finally, if you allow the environment clause to also provide an %alias keyword which could be used to influence proxy resolution within the query environment (including the navigation axis names themselves), personal preferences for naming conventions can be easily encapsulated within the queries themselves, making them useful, portable and completely isolated from anything else.

Given these three shifts in perspective in the way the specification is presented, I think that it suddenly becomes a whole lot easier to implement as everything related to interpretation of a particular world view is offloaded to a bootstrap (and potentially user-augmented) ontology- possibly using a set of aliases - and the behavior of the axes is defined in a consistent and user-extensible way.

Since this extensibility is based on interpretation of topic maps constructs in the query environment in consistent ways, the extensibility mechanism BRINGS NO ADDITIONAL COMPLEXITY to the TMQL environment implementation, and it provides huge value and benefit to exposing other graph-based ontologies beyond the TMDM to the TMQL environment using those exact same extensibility mechanisms.

Yes, I'm talking about TMQL as a unified graph query language supporting a BYOO (bring your own ontology) model of extensibility.  Graphs are paths, what the paths are called is pretty irrelevant.  Topic Maps are graphs with a given ontology.  Some people work at the TMRM level of "raw" subject proxies, and some people work at the TMDM level of Topics, Associations and Occurrences.

And the best part is, that's just fine. :)

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

_______________________________________________
topicmapmail mailing list
topicmapmail-Zo64W7twoUFWk0Htik3J/[email protected]
http://www.infoloom.com/mailman/listinfo/topicmapmail