Re: FYI: TMQL - New slides

Hi Benjamin,

On 2 Apr 2011, at 12:02 PM, Benjamin Bock wrote:

> On Sat, Apr 2, 2011 at 12:28 PM, Andrew S. Townley <[email protected]> wrote:
>> 
>> On 2 Apr 2011, at 9:21 AM, Benjamin Bock wrote:
>> 
>>>> [...]
>>>> So this would be
>>>> 
>>>> bb / homepage / value(xsd:anyuri)
>>>> 
>>>> compared to TMQL@rho
>>>> 
>>>> bb / homepage
>>>> 
>>>> ??
>>> 
>>> Well, if you're so crazy to store the homepage with a _different_
>>> datatype than xsd:anyuri, you'll of course have to convert it upon
>>> retrieval.
>>> If you store the homepage as xsd:string and want to retrieve it as
>>> string, you'd do:
>>> 
>>>  bb / homepage / value
>>> 
>>> . If you left out the "/ value", you'd get an occurrence object (as
>>> JTM or XTM fragment or TMAPI object or whatever... depending on the
>>> engine.
>>> 
>>> I didn't find where TMQL@rho does the automatic conversion xsd:string
>>> to xsd:anyuri, though. What's the heuristics? If value =~
>>> /web|homepage|url|uri/href/i ? Can you point me to it? Or can I just
>>> assume you're looking for differences where there are none?
>> 
>> 
>> Wait, you get an "object"?  Doesn't this unnecessarily tie you to the concrete model present in the underlying implementation?  Your response certainly implies this.  If so, doesn't that defeat part of the purpose of having a standardized query language?
> 
> If you don't like the name "object" you may as well call it "item" as
> it done in Robert's draft. The difference is the _auto_-atomication,
> not the atomification itself.
> 
> E.g. in Robert's draft, if you do:
> 
>    select $p >> characteristics homepage
>    where
>        $p isa person
> 
> you will get the occurrence items, not their values. Go to
> http://kill.devc.at/system/files/tmql-2008-07-15.html#SimpleContent
> and scroll *up* a tiny bit if you don't believe me.

The difference to me is in the assumption of the default and useful case.  I've read Robert's draft a few times, but I've never gotten around to going through it in enough detail to try and implement it.

Part of this comes back to my question of a few weeks ago in terms of what is the expected context of use for TMQL.

In my own work, I have to say that in the course of query operations, I've never had occasion to care about the "occurrence" itself, only it's value as either output or as input to further filtering as described in 4.5 of Robert's draft--and this all happens behind the scenes and within the engine implementation itself.  Sure, there are times when I need the "occurrence", but that's when I'm dealing with the proxy in its entirety and doing very specific manipulation based on ensuring multi-valued properties get recorded in the right assertion.

> What do you think how the query engine would return the occurrence
> item using Robert's draft?
> In TMQL4J, you can chose between JTM, XTM or a TMAPI object.

Well, I'd actually expect to be able to interrogate it as a TMRM proxy with path operations, e.g. (using an imaginary TMDM -> TMRM mapping):

  for $p in >> characteristics homepage
  where
       $p isa person

For each result $p, I'd be able to do 
   
   $p / value

or

   $p / datatype

because, to me, they're just named properties of the item returned which just happens to be a TMDM Occurrence characteristic with a few pre-defined properties.

I can't imagine that the enforced overhead to assume that the auto-atomification SHOULD NOT be done in the general case is a good thing for anyone.

If the characteristic things themselves are only useful within the context of a particular implementation language, as would be indicated by the format list you describe, then I'd wonder why you'd bother exposing this to a general-purpose query language at all.  How would I uniformly request a particular implementation to ensure that my queries would work across engines?

At the level of TMQL, I shouldn't care at all about the details or formats of an engine implementation, but I should have a unified model from which I could explore those representations in a consistent manner.

Bringing in artefacts like JTM, XTM or TMAPI into TMQL query results seems to me to be punching a large hole through the abstractions that TMQL would bring to TM applications.  What are the specific use cases you're supporting today that requires such activities?

> 
> First, the standard does not dictate which one to use or if any of
> these should be available.
> Second, this does *not* require the implementation to be based on
> TMAPI, it's enough to return empty wrappers which call back to the
> TMQL-engine for any information which is not inlined in the object.

If the standard indicates that occurrence items, objects or "things of name X" are returned, then it needs to also specify how those are handled in a general way that is independent of any underlying implementation.  If not, then it's really an API, not a query language.

Even those "empty wrappers" you mention have some implied functionality and characteristics, otherwise why would they be there?  As such, if they're exposed in TMQL, there must be TMQL constructs available to interact with them beyond representation-specific assumptions.

> 
>> It seems to me from the above that TMQL has become a mechanism for walking the particular implementation *object* graph represented by TMAPI/TMDM.  Even from my limited understanding of TMQL, this seems like a huge step away from Robert's draft which had a unified, underpinning model that was not tied to the TMDM (or any specific language binding or serialization thereof) directly but was based on TMRM and, in particular, the path navigation defined within it.
> 
> I hope I could enlighten your limited understanding a bit (-;

Unfortunately, no.  You've only heightened my confusion with the role of TMQL in the TM universe...

>> If the new TMQL is really just about walking Java object graphs that happen to relate to the TMDM, then why bother with the abstract syntax at all and just leave it down to "dot" notation for navigation through method calls and be done with it.
> 
> It's not and I hope this is obvious now.

I'm not so sure that I agree with you.  In places, I've gotten a lot of mileage out of this kind of approach for basic object graph navigation, so it does have it's place.  It also has some pretty extreme limitations.

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.

As it is, I fear the minimal implementation of a compliant TMQL is going to require a huge amount of effort to support everyone's pet boundary cases when these might not matter to the majority of TMQL implementation users or environments.  Addressing these boundary conditions via a built-in extensibility mechanism should allow for keeping the core straightforward, relatively elegant and reasonably easy to implement.

In case what I'm saying isn't clear, I'm saying that I believe the best TMQL would be to provide a concrete legend for the TMRM and as part of that legend, a set of extension points which would then allow consistent interpretation of how these extensions would be interpreted by any implementation.  We have many of these things already with CTM and TMCL, we just need a standard way to make them more interactive and dynamic.

Of course, I don't see a proposal such as the above getting much traction.... certainly not by June.
--
Andrew S. Townley <[email protected]>
http://atownley.org