[sc34wg3] TMQL: Environment Clause

[Robert Barta]

On Sun, Jul 20, 2008 at 02:52:30PM +0200, Lars Heuer wrote:
> Comments against TMQL draft dtd. 2008-07-15.
> 
> 6.3 Environment Clause
> ======================
> 
> 6.3.1 Directives
> ----------------
> 
>     "[...] For prefix directives each of the declared prefixes are
>     manifested as topics in the environment map (6.3) by using the
>     prefix identifier as topic item identifier and the namespace QIRI
>     as subject identifier [...]"
> 
> There seems to be no reason why a prefix should be defined as topic.

In principle it would be possible to place NS prefixes and their
URIs into a separate place, as CTM does it. So if someone writes

     %prefix a http://www.example.org/

then this will be registered. And of course it is possible to refer to
this information if someone uses the prefix. Since TMQL queries can be
nested, the safeplace for prefixes must be nested as well.

Of course this is possible.

But if an info architect from this century looks at this and says:

  - "Guys, a namespace URI for a vocabulary is nothing else
     than a subject identifier for that ontology!"

  - "Guys, everywhere you claim that TMs can be used for everything,
     but whenever they actually can be used in your own technology
     you are not using them."

  - "Guys, is this not a bit hypocritical?"

  - "And guys, in TMQL you already have a nestable place to put
     environmental information in, namely the 'environment map'.
     So why on earth are you not using that for namespace prefixes as
     well?"

Of course, I can stand up then and shout

  "Yes, you may be right, but we like to have it the old, syntactic
   ways."

Then the architect will slap his hand hard against his forehead and 
will die. End good, all good.

> According to ``6.3.1.`` the following would be valid::
> 
>     %prefix a http://www.example.org/
>     %prefix a http://www.another-example.org/
> 
> To which subject identifier is the prefix ``a`` resolved? There is no
> policy in TMQL: A user may define a prefix n times without any
> conflict, but it is not defined how to resolve that prefix.

The last para of 4.2 reads:

  .... Otherwise one such subject indicator ...

So it remains non-deterministic, if someone introduces
non-determinism. If that is not wanted, then there are ways to police
this. Not sure about that, though.

[ BTW should this above be "subject identifier"?]

> This would even get more complicated if the ``environment map``
> contains a topic with the item identifier "a" or a topic with the
> subject identifier "http://www.example.org/" or
> "http://www.another-example.org/": The prefix declaration may enforce
> a merging operation.

Merging takes place in _any_ case, because of the nested nature of a
TMQL expression. The environment created in the nested expression will
have to be merged into that of the outer expression.

This may actually be a clever way to deal effectively with ontologies.

> If TMQL would treat prefixes like CTM (c.f. draft dtd. 2008-05-15
> "3.14.1 Prefix Directive"), prefixes won't cause merging operations
> and TMQL would have a clear policy how duplicate prefixes are treated
> (as error if a prefix is bound to different IRIs).

Someone in a movies I heard

  Only a dead info architect is a good info architect.

but I could be wrong.

\rho