Re: TMQL - Proposal for a %base directive

Hi Andrew,

[tmql:ontology]
> From the usage in some of the unfinished supporting documentation,
> it would've seemed to me that you were also able to do some further
> definitions in-line, so it wasn't limited to just what could be
> retrieved and merged externally[1].

You're right.

[...]
> Unless you're specifying an overlay ontology with your base
> directive that isn't reflected in the effective map, wouldn't the
> effective ontology of your query match the effective map by default
> anyway?  If they didn't have subject indicators, the interpretation
> of the semantics is context-specific; if they did have subject
> indicators, then you'd be able to leverage these to ensure fixed
> semantics because the local identifiers in the effective map would
> resolve to the same items as the local identifiers in the TMQL query.

Yes, but what's the base IRI of the effective map? Topic Maps (acc. to
TMDM) contain always absolute IRIs, they don't have a concept for
local identifiers. (Topic Maps isn't any different from RDF in this
regard).

NB: The fact that Topic Maps (in TMDM) operate with absolute IRIs is
also one reason why I have my reservations against the "ident isa
tmql:ontology" mechanism. The "ident" would be an IRI too, and not a
small, cute local identifier.

TMQL must provide a mechanism to resolve the identifier "foo" into
some absolute IRI, otherwise queries which use "local" identifiers
would never return a result. At some point your local identifier must
become an absolute IRI and the proposed directive makes it more
explicit which (default) namespace you're using (for item
identifiers).

> Given that most of the rest of you seem to prefer fully-qualified
> names, that means you're likely to need to use multiple QNames in a
> given query anyway, so I'm not 100% sure I see the value in this use
> case.

Yes, a query would contain many QNames and probably a query wouldn't
rely on item identifiers but subject identifiers. As said, queries
like //person are very unlikely since "person" becomes an (absolute)
item identifier.

[...]
> is pretty necessary.  "Relative" rules in my world.  Absolute
> references are deferred until the last possible moment as best I can
> to ensure the first sentence remains true.

I see.

[...]
> A related question:  what would be the IRIs of the returned items?
> Aren't they still defined in terms of the effective "base" IRI of
> the effective map defined by the method of access?

The IRIs of any information in the topic map(s) wouldn't be altered or
resolved against the (query) base IRI. Since topic maps contain only
absolute IRIs they're returned as they are.

>> Given that, I can take my query and go from TM A to TM B without
>> re-parsing the query.

> I'm not sure I really understand the implications of this
> statement.

Reparsing is probably wrong, I meant, I get a query where the local
identifiers wouldn't be interpreted differently. Whether I go with my
query to topic map A or to topic map B, the local identifiers would
have been resolved already and they don't have to be interpreted
relative to some topic map.

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

> This kind of resolution is mostly what I'd expect.  I think the
> difference is when the expansion actually occurs (at least to me).

That's correct. I'd prefer that the expansion happens within the query
parser and that local identifiers become absolute IRIs as early as
possible and local identifiers wouldn't have to be resolved relative
to the topic map.

[...]
> However, based on the byte-sequence-as-identity implied by using
> only local, unqualified identifiers, the semantics of the *query*
> would remain the same across maps and be consistent within the
> bounds of TMQL.  The only difference I see is in the expectations of
> the semantics reflected by query results.  In reality, while
> similar, they're actually asking two different questions, hence the
> variability of the results in the second case.

I agree.


[...]
> Second, I think the example above actually illustrates the issues
> with prefixes vs. proper QNames we've discussed before.  The fact
> that you're really doing string-concatenation

No, I don't do simply string-concatenation. IRIs are resolved acc. to
RFC 3986.

[...]
>         [49]    prefix-directive        ::=      %prefix   identifier QIRI

> This is one of the definitions that's admittedly made me scratch my
> head a bit because I would've expected an IRI here instead of QIRI.

Me too. Probably this is simply a mistake in the grammar.

> In my own experience, the only reason to use any kind of base
> definition is to reduce the typing burden or to apply additional
> context to something more generally defined.  Either way, it's still
> a mechanism to help the humans, so, as such, I just didn't see why
> you wouldn't let people use it as they saw fit.  I wouldn't really
> see how it would make much difference to the parser.

Multiple base IRI directives would be possible, I just wanted to keep
it simple. I think it does more harm than good if foo is sometimes
(within the same query!) resolved against IRI A and sometimes against
IRI B. If we allow multiple base IRIs, we can also ask us why prefix
mappings are immutable and we don't allow multiple bindings to the
same identifier.

[...]
> If it's really about saving keystrokes, I don't see the value in
> making it immutable.  The only scope of applicability is within a
> given TMQL query or, by extension, some application-defined query
> session.  It doesn't apply to the effective map, or are you thinking it would?

It wouldn't apply to the effective map directly, but it changes the
interpretation of all local identifiers. The parsed query would
contain absolute IRIs, only.

[...]
> Yes, I absolutely assume a local namespace, but not necessarily a
> base IRI (if that makes sense). These can vary completely
> independently for me.

Yes, I think that's the key difference. I expect absolute IRIs
everywhere while you can work with local ids in your environment.

[...]
> I've never used tolog, so I can't say how closely my environment
> matches tolog.

Well, I don't want to use tolog as "bad example". tolog works well and
it would be possible to introduce a base directive (I did). I just
used tolog as an example how local identifiers are resolved.

[...]
> However, as I understand the TMQL specification, the
> syntax of the queries themselves should be portable across maps. The
> questions come down to:

>         1) Does the map actually contain local relationships to
> satisfy the query?  If not, no results.
>         2) Do the semantics of those local relationships match the semantics implied by my query?
>         3) Do I care more about the structure or semantics of the query result?

ACK.

But at some point TMQL has to specify how local identifiers are
interpreted. AFAIK it is underspecified in this regard.

[...]
> If tolog actually pre-resolves the local identifiers relative to
> the local map as part of the parsing phase, I'd view that as an over-eager optimization.

I think that's not specified. The tolog specification simply says that
identifiers become item identifers and are interpreted relative to the
current map's IRI.

[...]
> The goal certainly makes sense, but I wouldn't see any reason that
> what I describe would preclude this sequence.  Like always, if it
> really, really matters, pre-qualify exactly what you want to happen
> as much as possible, e.g. use prefixes or fully-qualified IRIs.

I agree. The proposed directive would simply make the interpretation
of local identifiers more transparent, imo.

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