[tmql-wg] Comments against TMQL draft 2006-02-22

[Lars Heuer]

Hi Robert,

[...]
>    jack / name

> should work is that 'name' is a _valid_ item reference of a topic in
> every map(!) for the TMDM concept
[...]
     http://psi.topicmaps.org/iso13250/model/topic-name


But your definition seems to match the concept of a default namespace
with an additional alias "name" for "topic-name". In fact you're using
the TMDM namespace as default namespace. I don't see a difference. The
only difference is, that you use a meta-topic map to import the
identifiers for "name", "occurrence" etc.


[...]
>    lheuer isa person
>    ! irc-nick: lheuer
>    ! fullname: Lars Heuer

> Here I would argue that implicitely

>    irc-nick iko name
>    fullname iko name

Jep. But it seems not to be a CTM issue but an general issue for all
Topic Maps syntaxes, resp. Topic Maps itself. In Leipzig we discussed
the a kind of "meta"-map that might be the solution.

[...]
>> - Prefix "tm"
>>   The prefix "tm" cannot be bound to 
>>   "http://psi.topicmaps.org/iso13250/glossary/"
>>   but must be bound to "http://psi.topicmaps.org/iso13250/model/"
[...]
> I think you are right, but I cannot find a place where

>    http://psi.topicmaps.org/iso13250/model/

> is defined as namespace. Could be just me being tired.

It is only mentioned in the text of the TMDM. Not the best choice for
such an important thing, though.

[...]
>> - Prefix "tmql"
>>   Why is it not just "ql"?

> No particular reason, except maybe that TMQL is already a mnemonic. ql
> is not.

Ok. Well, I have no strong feelings here, just thought it would be
nice to define all namespaces with two letters. ;)


>> 4.2 Atoms
>> ---------
>> - "This International Standard recognizes natively a small set of 
>>   primitive data types..."
>>   I.e. "qname" is neither a native nor an primitive datatype in 
>>   "XML Schema Part 2: Datatypes Second Edition"-sense.

> Probably I do not understand something properly, because QNames are an
> XS type:

>     http://www.w3.org/TR/xmlschema-2/datatypes.html#QName

> I'm a bit flaky on this one, so help/education is welcome.

Namespaces in XML
<http://www.w3.org/TR/1999/REC-xml-names-19990114/#dt-qname> has the
following grammar for QNames:

          [6]     QName      ::=    (Prefix ':')? LocalPart
          [7]     Prefix     ::=     NCName
          [8]     LocalPart  ::=     NCName


But in TMQL the "Prefix" and ":" are never optional for TMQL-QNames.


>> - [7] iri
>>   IRIs must be encapsulated by '"'; why?
[...]
> There is another issue here: In
>    http://en.wikipedia.org/wiki/John_Winston_Lennon
> and
>   "http://en.wikipedia.org/wiki/John_Winston_Lennon"
> the first one is an IRI used as subject identifier. This goes done
> rule [8] and the second one is an atomic value of type anyURI (or
> whatever that type is). That is rule [7].

Ah, okay. Then it's a failure in the grammar, because

    [13] item-reference ::= identifier | qname | iri

uses the same rule [7] (with the quotes).

[...]
>>   IMO this rule should be moved to a "QName" rule

> You mean that he rules

>     qname -> prefix identifier
>     ....

> should be seperated from the atoms a bit and the explanatory text be
> put underneath?

Yes, I think the qname rules are a bit underrepresented.

>> 4.4 Navigation
>> --------------
>> - [15] axis
>>   Several axis use a terminology (i.e. "classes") which is not 
>>   aligned to TMDM.
>>   Consider to align the axes names with the TMDM-terminology

> Definitely. In fact, I would love to see this whole axes business move
> into TMDM at some point. It has nothing to do with TMQL, not?

Sorry, I don't understand what you mean.

> So this means that 'class' should be replaced with 'type'. And
> superclass with supertype...

Yes.


[...]

>> 4.10 Topic Map Content
>> ----------------------
>> Do we need this section at all? How is CTM different from any other
>> textual content?

> In that, that this is NOT text. If I write

> for $p in // person
> return
>     """
>        $p isa terrorist
>     """

> TMQL does NOT return text strings which are then parsed by the
> application into a map. TMQL creates already these TM fragments and
> merges them together as it goes.

Hmm.... I am not sure that I've understood this feature. If it returns
something that represents a topic map instance (however that is
representented), it has nothing to do with CTM, but with the feature
to generate topic maps on the fly and to return such a structure.

If it returns a CTM instance / stream (again: whatever that is): How
does the TMQL-processor know that it returns CTM? Isn't a datatype
indicator missing?

I.e.:
     for $p in // person
     return
     """
       $p isa terrorist
     """^^http://www.topicmaps.org/ctm/



Best regards,
Lars
-- 
http://www.semagia.com