Re: TMQL - Proposal for a %base directive

Hi Lars,

On 3 May 2011, at 9:20 AM, Lars Heuer wrote:

> 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.

I think it's intentionally vague to allow TMQL to query and surface information from a variety of existing and future map specifications.  Personally, I disagree that TMQL needs to define how to resolve local identifiers, because intrinsically, local identifiers are part of the local map implementation.

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.  I see *that* they are exposed in some way that's consistent being much more important than *how* they are exposed.

> [...]
>> 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.

I'm extrapolating this a bit from a blend of looking at both RDBMs implementations as well as the way content is published on the Web because I'd see topic maps implementations as somehow similar to 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.

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.

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

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.

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.  I also have a way to explicitly specify a base IRI to which unqualified local identifiers should be parented when using the command-line tools.  Once a map mount has been defined for the Pragmantix engine, it doesn't matter what the physical serialization is nor where it is physically located.

I would assume that other systems would provide some kind of mechanism intended to solve the same problem, but perhaps without the same amount of complexity and redirection. ;)

Maybe this isn't the case for other systems.  However, if it is, that's why I said what I said and asked the question.  While the topic map in the abstract doesn't have an address, in order to be useful, it must be accessible in some way that can be re-cast as an 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.

> 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.

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.

> 
> 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?

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).  This would allow either all maps to be addressed separately and directly (therefore providing unambiguous resolution to unqualified identifiers defined within each of those maps, or it would allow addressing any of the identifiers in terms of a virtual, intermediate representation of the three maps via the %_ environment map construct (which may be omitted), effectively making them unqualified identifiers within the virtual map (pending whatever merging operations apply to the particular view exposed through the environment map).

There's nothing stopping an implementation environment from providing a transitory or even a permanent base IRI for this resulting view.  As per the application of the transformations in TMRM, the results are a *new* map.  This map may happen to only include proxies present in a previous map, so addressing the resulting proxies in terms of the original map would be perfectly valid (and they would have the same effective, if not logical, base IRI).  If new proxies are created, then it should be possible to route these to either temporary or persistent addresses.

This is effectively the model used by SQL result sets and defined via the SELECT...INTO... construct in SQL.  I think this approach applies equally well in the case of TMQL.  SQL doesn't define the way to address particular tuples in a result set unless you explicitly target those results to a location.  Once you've done this, you can access this location using the normal naming/addressing schemes present in your implementation environment.  In SQL, this is a flat namespace with tables and views as the only addressable subjects.

In TMQL, you're always dealing with a single environment map that manifests a unified view across some set of proxies, each of which should have some unique identifier defined as part of how the environment map view is created.  By default, your result tuples contain references to items in the environment map, but, because IRIs are valid identifiers, some of these may actually be referencing other physical maps.  Alternatively, these identifiers (if not created as part of the TMQL query/statement) would be resolved in terms of the "native" addressing scheme of a default map used to construct the effective map environment.

> [...]
>> 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.

I don't really agree, but I'm sure there are plenty of ways to ensure maximum incompatibility... ;)

Still, I see this as the same problem with how you uniquely identify content contained in a single HTML file or SQL dump.  You have a number of potential addresses, but the content is only useful once it's published at a given location.  The scope of usefulness would obviously differ depending on the access mechanism, but TMQL should be just as functional when applied to everything from an in-line map with nothing but local identifiers to a globally distributed network of topic maps endpoints accessible via a variety of transport protocols.  I don't see that trying to nail down addressing would enable this goal.

> [...]
>> 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.

Yeah.  I think you're right.

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

No worries.

Cheers,

ast
--
Andrew S. Townley <[email protected]>
http://atownley.org