Re: TMQL - Proposal for a %base directive

Hi Andrew,

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

> I think it's intentionally vague to allow TMQL to query and surface
> information from a variety of existing and future map
> specifications.

Leaving this intentionally vague works for me, you and rho having
downed some orange juice, but it does not work for an international
standard. At some point you have to state clearly how local
identifiers have to be interpreted.

And since TMDM is an ISO standard and TMRM isn't, TMQL will be aligned
to TMDM, regardless how sexy TMRM might be.

> Personally, I disagree that TMQL needs to define
> how to resolve local identifiers, because intrinsically, local
> identifiers are part of the local map implementation.

I am afraid that TMQL has to define it. Otherwise it wouldn't become a
standard.

Maybe layering the standard would help to some extent but at some
point the standard must state what "resolving items to the context
map" means concretely.

> In my view, to try and specify how this resolution should take place
> would place a set of assumptions or undesirable constraints on TMQL
> implementations, and by extension, topic maps systems, on how items
> should be exposed.

Okay, maybe we have to distinguish between TMQL and its foundation.
TMQL's foundation is TMRM. TMRM's path expressions work without
absolute IRIs and TMDM's overhead. But TMQL (at least the level which
is exposed to the average user) must respect the constraints of TMDM.
A layered approach may work, though (even if I doubt that this will
happen). Personally, I'd agree that a layered approach would be nice,
but at least we have TMRM's path expressions without any standardized
syntax (a TMRM layer may define a query syntax, though).

[...]
> both of these types of systems.  Your "topic maps don't have an
> address" statement is exactly the reason that I prefer local
> identifiers over fully-qualified IRIs, BTW.

An agreement ;)

> What I meant by the above question is that the "published" address
> is a function of the publication mechanism, and that's entirely
> dependent on the access mechanism used by the publisher.  If you
> have an XTM or CTM file, that file defines the boundaries of the
> effective map after resolving any external implicitly or explicitly
> merged maps.  Each of the external maps would also have some kind of
> address, otherwise you won't be able to complete the merge operation.

ACK.

> Starting with the simple case - if no external references exist -
> if you were to load the map into a topic maps environment, you'd
> have a few different choices for defining an IRI for resolution of internal identifiers:

>         a) the filesystem path location of the source map, e.g. file:///some/path/to/map.xtm,
>         b) the mechanism that clients would connect to the server
> implementation to access the information within the map.xtm instance,
>         c) some kind of serialization-specific explicit base location specifier

In a previous msg you said we should escape from the one topic map per
document/resource assumption and now you present only one topic map
per resource options.

> If you choose b) and you access the map via HTTP, then you get some
> absolute IRI as a basis for the map.  If you choose b) and you
> access the map via TMAPI, then you might have some kind of
> tmapi:map@host hypothetical IRI that could be used as the base IRI for local identifiers.

ACK.

> Not that it's a direct apples-to-apples comparison, but for
> Pragmantix, I have a hierarchical tree of mount points like a
> filesystem, and I've defined a custom URI scheme to define how
> resolution within this tree takes place.  This is the second of the
> multi-level addressing schemes I mentioned in a previous mail.  To
> access any proxy, I can use something like:

>         ame:/map1/proxy1

> I can also parent unqualified references to proxy1 using a base IRI
> established through direct access to a map through a 3rd-level
> addressing scheme such as HTTP, e.g.

>         http://example.com/map1/proxy1

> where the base context of http://example.com maps to the root mount
> of the Pragmantix instance, making the level 3 HTTP IRI
> http://example.com/map1 map to the level 2 Pragmantix IRI ame:/map1.
[...]

That's all well and good. But you define a resolution mode which may
not work for the TMQL implementation X. Your implementation isn't a
standard. Is your resolution the same as the local identifier
resolution in Perl::TM? Maybe it is, but I am talking about a standard
with standardized test cases etc.

[...]
> IRI (even if it follows the JDBC IRI model for some custom API
> access path) that should be used as the base IRI for local identifiers.

We cannot assume that. What happens if the map is a stream without any
information about the source IRI of the stream? At some point we have
to provide an address. AFAIK all recent standards (even those which
work on an abstract model) like XPath/XSLT/XQuery or SPARQL require
some address to resolve identifiers against. And all standards define
a standardized resolution mechanism on purpose.


[...]
> True, but it sees that one map through the lens of the
> implementation on which it is built.  There's a number of ways this
> could be done, but as it's based on local map addressing in terms of
> the engine, I don't see why this is a big deal.

At some point you have to be concrete.

[...]
> None of the above.  The address of your environment map would be
> based on the mechanics of providing the view of these maps to the
> processor (in terms of the engine's accessing mechanisms).

Okay, but at some point you have to become concrete. That's the way
how standards work.

Even if I like your view, this view does not work for ISO standards.
I bet that your implementation of TMQL delivers different results than
the TMLab's implementation or rho's implementation.

Again, I have to skip the rest of your msg, now due to sleep
constraints. :) But in general I don't think that our positions are
far away, I'm just wearing my ISO standard hat.

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