Re: TMQL - Proposal for a %base directive

Hi Lars,

On 29 Apr 2011, at 12:41 PM, Lars Heuer wrote:

> Hi there,
> 
> A minor proposal for TMQL:
> 
> In tolog each identifier (and IRI) like foo is resolved against the
> base IRI of the queried topic map. In the current TMQL draft (2008)
> the resolution of identifiers is not specified, so I assume that IRIs
> and identifiers are also resolved against the base IRI of the topic
> map (if I understood it correctly, the tmql:ontology topics only jump
> in if QNames should be resolved).
> 
> I find that behavior suboptimal for the following reasons:
> * Topic maps do not have base IRIs
> * I cannot re-use a parsed query with another topic map since the
>  identifiers (and IRIs) have to be resolved relative to the current
>  topic map

For this second point, if an approach similar to my "bring your own ontology" BYOO suggestion was used, I don't think query re-use would be a problem.  In fact, query-reuse was one of the primary motivators for it.

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.

If you could do this, wouldn't it be possible to qualify only as necessary to facilitate the query behavior you intended?

> To cut the long story short, my proposal would be a base directive
> like
> 
>   base-directive ::= '%base' iri
>   iri            ::= CTM's def. for IRIs
> 
> If no base IRI is defined, the resolution of identifiers/IRIs may be
> application dependent (c.f. RFC 3986 5.1.4.). If the base IRI
> directive is used, it MUST be the first directive before any %prefix
> directive. This proposal mimics the base IRI definition for SPARQL.

This would then influence the resolution of any literal, unqualified identifier appearing anywhere in a given query, right?  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?

I think I understand what you're trying to achieve, but I'm just a little confused.

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:

%base ...
[TMQL query 1 using ontology referenced from base]
[MAGIC APP-DEFINED QUERY DELIMITER]

%base ...2
[TMQL query 2 using ontology referenced from 2nd base]

I've thought about this sort of thing for my own ongoing implementation, but mine isn't really based around fully-qualified IRIs in the majority of cases.  However, I'm going to need something like this anyway, so it would be nice to have similar semantics to the official interpretation.

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

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.

Rightly or wrongly, maps for me have a local namespace that includes anything that is not otherwise more fully qualified.  This is similar to relative paths in filesystems (and IRIs).  Naturally, you can explicitly or implicitly introduce additional scope - perhaps on how the map is accessed, e.g. via a fully-qualified IRI which effectively becomes the base as per above, but I don't believe that explicit scope should be required or is necessary in many scenarios.

I guess it just depends on your modeling approach and the way your information is structured.

...or, maybe I'm just weird (but we all knew that anyway) ;)

Cheers,

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