Re: TMQL - Proposal for a %base directive

Lars Heuer <[email protected]> Tue, 3 May 2011 10:20:40 +0200
Newsgroups gmane.text.xml.xtm.general
Organization Semagia
Message-ID <[email protected]>
Hi Andrew,

[...]
> As for the base IRI of the effective map, isn't this entirely
> dependent on the access mechanism?

I am unsure if I understood this question.

IMO TMQL has define somewhere how to resolve local identifiers. It has
to it regardless of the %base proposal. Section 5.1 defines:

       """
       [Context map]

       [...}
       All item references and navigation steps are interpreted
       relative to this map.
       """

I think that this definition is rather vague, maybe intentionally.

[...]
> However, as you say, if you ever did need to resolve the ident, yes
> it would have an IRI that would effectively be an alias for some
> other construct used in the TMQL query.  Again, though, I don't see
> this as a real issue.  If you look at the TMQL query and the
> environment as a map itself, then it too can have a published
> address, giving everything within it a fully-qualified IRI that
> would seem to play well with your world view.

I agree, but how does it get this address? Topic maps don't have an
address.

And if the effective map is a view on 1..n maps how would you resolve
your local identifiers relative to the underlying maps? The query
processor sees just one map.

Let's assume for a moment that topic maps have an address. map-1 has
base-1, map-2 has base-2 and map-3 has base-3. My environment is a
view on map-1 + map-2 + map-3. What's the address of my environment
map? Is it base-1, base-2 or base-3?

[...]
> I believe that the mechanism you describe is purely a function of
> the way the particular TMQL query environment works rather than
> being the responsibility of TMQL to define.

If TMQL left this undefined we don't have a reliable specification
since each vendor may interpret the address resolving mechanism
differently and query A may work in system B but not in system C.

[...]
> This again is one of the other reasons that I thought a modular TMQL
> specification would be a good way to go. If you have the more
> general and abstract concepts specified in one document, then you
> can specify particular, standards-compliant mechanisms and behaviors
> for exposing this functionality based on particular environments
> like TMDM or in terms of pure TMRM path expressions.

Probably this would be a solution although I have my doubts that this
will happen provided that the current focus seems to be TMDM.

Sorry, I have to skip the rest of your mail.

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

<https://twitter.com/larsheuer/> Twitter
<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