Re: FYI: TMQL - New slides

On 2 Apr 2011, at 9:21 AM, Benjamin Bock wrote:

> Hi Robert,
> 
> On Sat, Apr 2, 2011 at 9:43 AM, Robert Barta <[email protected]> wrote:
>> On Fri, Apr 01, 2011 at 11:42:17AM +0200, Benjamin Bock wrote:
>>> Hi Robert,
>>> 
>>> On Fri, Mar 25, 2011 at 8:45 PM, Robert Barta <[email protected]> wrote:
> 
>>>> I know that TMDM hold the "data type" within the occurrence node
>>>> 
>>>> http://www.isotopicmaps.org/sam/sam-model/#sect-occurrence
>>>> 
>>>> [yes, weirder things have happened], but TMDM also assumes that values
>>>> are all strings.
>>>> 
>>>> As this cannot be the case for TMQL (it has to be able to apply numeric
>>>> operators), why is this maintained in Slide 21ff ?
>>> 
>>> The datatype axis is provided to enable access to anything which is
>>> available in a TMDM topic map.
>>> The value axes returns objects in their original datatype. We consider
>>> something oc1 / value(xsd:string) or string(oc1 / value) to return
>>> objects converted to another datatype (string in this case).
>> 
>> 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?

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.

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.

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