[sc34wg3] TMQL - Comments against draft dtd 2007-07-13

Fri Oct 19 08:36:15 EDT 2007

Lars,

Several of the issues you list were discussed in Leipzig. I will be posting
the notes from that meeting as soon as I have received them all from the
editors. I suggest you wait until you have seen those documents and then
repost whatever comments have not been addressed.

Steve

| -----Original Message-----
| From: sc34wg3-bounces at isotopicmaps.org [mailto:sc34wg3-
| bounces at isotopicmaps.org] On Behalf Of Lars Heuer
| Sent: 19 October 2007 13:46
| To: Discussion of ISO/IEC 13250 Topic Maps
| Subject: [sc34wg3] TMQL - Comments against draft dtd 2007-07-13
| 
| Hi all,
| 
| As I know, the TMQL have nothing special to do this weekend, so here
| some TMQL comments ;)
| 
| 
| Topic Maps -- Query Language
| ============================
| 
| Namespaces
| ----------
| - TMQL is silent about a mechanism to define namespaces. It
|   uses QNames but it seems to be impossible to define these.
|   (we have some predefined prefixes, but how does the user define
|   one?)
|   TMQL mentions the environment (section 6.3) but wouldn't it
|   be good if the user can define prefixes for a query ad hoc?
|   (see also my comments for section 6.3.)
| 
| 
| 4.3. Item References
| --------------------
| - [A] item-reference ::= *
|   CTM uses the wildcard '*' to create a (more or less) anonymous
|   topic. If CTM uses '*' for that purpose, it is confusing if
|   TMQL uses the same syntax to refer to a specific topic which
|   is defined as 'tm:subject'. Either we should blame the CTM
|   editors or the TMQL editors for that confusing overlap
|   (I can imagine the answer from the TMQL-editors ;)).
| 
| 
| 4.4. Navigation
| ---------------
| 
| - [B] step::= >> instances
|   'instances' is not part of production [18]. Either this axis should
|   be added or the forward direction should be removed, and therefor
|   only '<<' 'types' should be a valid axis.
| 
| - I wonder if we can reuse the 'isa' (is instance of) and 'ako'
|   (a kind of) keywords somehow instead of introducing 'types'
|   and 'supertypes'.
| 
| - I wonder if we should move those axes where the 'anchor' is ignored
|   to another production. If the 'anchor' is ignored anyhow, why should
|   we allow to specify it? If an 'anchor' is specified where it is
|   ignored, an error would be more helpful than ignoring it silently,
|   IMO. If I understand the production correctly, the following
|   statement::
| 
|         person << types
| 
|   is equivalent to this one::
| 
|         person << types
| <http://www.something.which/is.ignored.but.allowed>
| 
|   The 'anchor' seems to have only a relevance for the following
|   productions:
|   - players
|   - characteristics
| 
| - 'locators' / 'indicators'
| 
|   - Any chance, that TMQL adapts the CTM syntax for subject
|     identifiers / subject locators?
|     (TMQL uses '=' and '~' as suffix, CTM does not use ~ for subject
|     identifiers at all and uses = as IRI-prefix for subject locators)
|     Is the '~' necessary at all? Why is not every plain old IRI a subject
|     identifier?
| 
| - 'reifier'
|   - Wouldn't be one tilde enough? Instead of '~~>' we could use '~>'
|   - Why is the forward shortcut ~~> defined, but not a backward shortcut
|     (<~~)?
| 
| - The 'characteristics' axis:
|   - Is the 'anchor' necessary at all? Isn't it possible to use
|     ``tm:occurrence`` and ``tm:name`` (or to be more exact
|     ``tm:topic-name``) as axis and ``tm:characteristic`` to retrieve
|     both: names and occurrences? Maybe it becomes more complicated if
|     the user wants a specific type, but if 'isa' could be reused, the
|     following seems to be possible::
| 
|     a)  john >> tm:occurrence [. isa homepage]
| 
|         retrieves all occurrences of type 'homepage'
| 
|     b)  john >> tm:name [. isa nickname]
| 
|         retrieves all nicknames from the topic 'john'
| 
|     c)
|         i.  john >> tm:characteristic [. isa whatever]
|         ii. john >> whatever
| 
|         retrieves all characteristics (names *and* occs) of type
| 'whatever'
| 
|     d)  Retrieving all occurrences by foot:
| 
|         john >> tm:characteristic [. isa tm:occurrence]
| 
|     e)  Retrieving all names of type 'nickname' by foot:
| 
|         john >> tm:characteristic [. isa tm:name][. isa nickname]
| 
|         or:
| 
|         john >> tm:characteristic [. isa tm:name & . isa nickname]
| 
| - While writing this, I wonder if the need these uniform axes at all.
|   Why do we need the << >> axis incl. keywords, if we'd introduce some
|   specific "axes": ako, isa, <-, ->, ~>, <~ (the last four axes are
|   already part of TMQL). Well, I may be mistaken here, but we could
|   remove some (lengthly) keywords and introduce a dedicated syntax for
|   them.
| 
| 
| 4.7. Composite Content
| ----------------------
| - I just want to mention, that I find the '==', '++' and '--' infix
|   operators confusing / not very intuitive
|   - for intersection ('==') I'd use '&'
|   - for union ('++') I'd use '|'
|   - for difference ('--') I'd use '-'
| 
|   Well, it's just syntax and '&' and '|' are already used for 'and'
|   and 'or', but ... hmmm ... anyway ... I'll move on
| 
| - Has someone verified, that the condition (if .. then .. else ..) is
|   unambiguous (even if conditions are nested)?
| 
| 
| 4.10. Topic Map Content
| -----------------------
| - The topic map content is wrapped inside triple quotes ("""), but
|   CTM itself uses triple quotes. Maybe another syntax should be used
|   to wrap topic map content, otherwise the implementator has to
|   count the number of """ to decide if the topic map content block
|   is closed or if a CTM string is opened / closed.
|   Additionally, this is bad for syntax highlighers etc.
|   If TMQL uses another syntax as wrapper for topic map content, it would
|   be more obvious that the content is not necessarily a string, but
|   a topic map content stream (whatever that is).
| 
| 
| 4.13. Boolean Expressions
| -------------------------
| - see 4.7. :/
| 
| 
| 6.3. Environment Clause
| -----------------------
| - The environment clause seems to be a string, why does TMQL not adapt
|   the directives from CTM? Maybe TMQL could add some directives for
|   setting the default topic map etc.
|   - If TMQL adapts the CTM directives, we should check if
| 
|         '%' directive-name
| 
|     violates the syntax for the context / environment map
|     (c.f. 5.3. Variables)
| 
| 
| 
| Best regards,
| Lars
| --
| http://www.semagia.com
| 
| _______________________________________________
| sc34wg3 mailing list
| sc34wg3 at isotopicmaps.org
| http://www.isotopicmaps.org/mailman/listinfo/sc34wg3