Re: TMQL - Proposal for a %base directive

Hi Andrew,

> My (perhaps incorrect) understanding of one purpose of the tmql
> local ontology was so that you could potentially assign additional
> subject indicators to "local" identifiers to allow you to extend and
> interpret the information in the effective map in particular ways to
> ensure consistent query results.  The tmql:ontology type itself I
> understand to represent entire namespaces.

I think that's almost correct.

  %prefix foo <http://psi.example.org/onto>

becomes (acc. to my understanding) in the effective map:

  foo isa tmql:ontology;
     <http://psi.example.org/onto>
  .

If the TMQL processor finds a QName, it asks the effective map for the
prefix and concatenates the local part of the QName with the subject
identifier.

It's the same mechanism which is used in CTM and other syntaxes, but
with the nice side effect that you can query the effective map for

     //tmql:ontology

to retrieve all prefix definitions. At least the idea is nice, I am
unsure if it has any advantages over "normal" prefixes like the ones
used by CTM. IMO it simply adds unnecessary complexity. I am sure rho
disagrees. :)

I think it's possible to translate the %base directive as well to
Topic Maps.

   %base <http://psi.example.org/base/>

could become:

   <http://psi.example.org/base/> isa tmql:ontology.

So, a tmql:ontology without a local identifier (item identifier) can
be used as base IRI.


[...]
> This would then influence the resolution of any literal,
> unqualified identifier appearing anywhere in a given query, right?

It would effect any IRI and unqualified identifiers, yes.

   %base <http://psi.example.org/onto/>

   select $album
   where is-produced-by (production: $album, producer: tom-waits)


would become:

   select $album
   where ^<http://psi.example.org/onto/#is-produced-by>(
         ^<http://psi.example.org/onto/#production>: $album,
         ^<http://psi.example.org/onto/#producer>:
         ^<http://psi.example.org/onto/#tom-waits>)


(^ indicates an item identifier in CTM)

Given that, I can take my query and go from TM A to TM B without
re-parsing the query. In tolog I cannot do that. A query is always
bound to a topic map. If the topic map is stored at
<http://www.example.org/map/a> the above query becomes:

   select $album
   where ^<http://www.example.org/map/a#is-produced-by>(
         ^<http://www.example.org/map/a#production>: $album,
         ^<http://www.example.org/map/a#producer>:
         ^<http://www.example.org/map/a#tom-waits>)

If the TM is stored at <http://www.example.org/map/b> it becomes:


   select $album
   where ^<http://www.example.org/map/b#is-produced-by>(
         ^<http://www.example.org/map/b#production>: $album,
         ^<http://www.example.org/map/b#producer>:
         ^<http://www.example.org/map/b#tom-waits>)

If the TM is stored at <http://www.example.org/map/c> it becomes ...
well, I think you got the point... ;)

If it's possible to query multiple maps with TMQL, each identifier
like "tom-waits" has to be resolved relative to each map IRI.


[...]
> Also, I'm assuming you're not specifying ordering of the directive
> relative to prefixes, but rather the resolution precedence?  In
> either case, why the MUST qualifier?  Wouldn't QNames (at least as
> defined in CTM/TMQL as prefix-substitution constructs, automatically
> be orthogonal to local identifier resolution anyway?

Well, the "MUST" avoids problems.

Example:

  %prefix a <#foo>
  %base <http://www.example.org/>
  %prefix b <#bar>


Here we have to resolve the prefix IRI <#foo> against some (undefined)
base IRI (application dependent) while the prefix IRI <#bar> is
resolved against our base IRI <http://www.example.org/>.

While that would work, I thought that having the %base at the top is
more clear and wouldn't lead to surprises.

> Also, presumably, if you specified a base directive, it would only
> remain in effect until the logical "end" of a query session or
> another base directive was issued, e.g:

Yes, but I wouldn't allow more than one base directive, conservative
as I am. The base IRI should be immutable. For all other use cases,
the prefix mechanism should be used (at least this should work for
TMDM, maybe you'll disagree since you seem to use local identifiers
very much).

>> An alternative to the base IRI directive might be a more radical
>> "no-identifiers policy", so a query must only use absolute IRIs (and
>> QNames), since relative identifiers have a doubtful value anyway.

> I think this is a bad idea (at least from my perspective and
> implementation). In my world, relative identifiers have very high
> value. If I wanted to require fully-qualified URIs for everything,
> I'd just use RDF. ;)

:) I see.


> More seriously though, my general modeling approach is more similar
> to the use of xs:include with W3C XML Schema in that I use local
> identifiers where convenient and then qualify them as necessary
> using either subject indicators or subject locators to provide more
> concrete identity assertions.  This means that local/relative
> identifiers do have value within the context of the query.

I see. Well, that seems to match the tolog local identifier resolution
mechanism (if you interpret the base IRI of a topic map as local
namespace). That implies that your tolog queries may no longer work if
you change the base IRI (that holds also true for the proposed %base
directive). I think that the %base directive makes the local namespace
simply more transparent/obvious and provides the advantage that a
query processor may be self-contained: It can resolve IRIs
independently of the concrete topic map (and its base IRI).

My use case was something like this:

   stmt = conn.prepare("some query here")

   stmt.context.add_map(<IRI-1-HERE>)
   stmt.context.add_map(<IRI-2-HERE>)

   res = stmt.execute()

   stmt.context.remove_map(<IRI-1-HERE>)

   res = stmt.execute()

I can modify the effective map without taking any of the topic map
base IRIs into account since the query stays always the same. I don't
have to recompile/re-parse the query just because my context map has
changed; the query is immutable.

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

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
<http://mappa.semagia.com/> Mappa - Python Topic Maps engine