Fwd: Re: [sc34wg3] Feedback on TMDM

[Robert Barta]

On Fri, Apr 22, 2005 at 01:43:43PM +0200, Lars Heuer wrote:

> > - 5.1: Source Locators
> [...]
> >   Or less futuristic, if the map is built up in memory from
> >   scratch (no deserializable syntax in sight). In this case
> >   you would not have any source, so no source locator.
> 
> >   Isn't it the agenda to "address the item" itself regardless
> >   where it may have come from (which may not exist anymore)?
> 
> Once you attached a source locator to an item it is stable (unless you
> remove it). I understand source locators as (more or less) persistent
> identifiers.

So do I, but they do not have anything to do 'from where' (source) the
topic actually originates. As Jan (Algermissen) said before, this can
be just an ephemeral data stream over the wire.

> [...]
> > - 5.1: Constraint
> 
> >   They cannot be the same unless items are topics. In that case, these
> >   have to be merged. So there is only one topic afterall. So the source locators
> >   are different afterall for _EVERYHTING_! Or not?
> 
> I don't understand the last but one sentence. :(
> If you merge items they get the union of source locators from all
> merged items.

The text there runs:

  "It is an error for two different information items to have string
  that are equal in their [source locators] properties, unless they
  are topic items. If they are topic items they must be merged
  according to the procedure in 6.2."

If I take any two items which do not happen both to be topic items,
then the constraints sounds ok.

If I take two topic items, then I may wonder how it can happen that -
within a map, following all constraints, also those concerning merging
- it can happen that these two items are two different, but have to be
merged.

If the [source locators] are the same, then the two have to be merged
in the first place, so there is only one. And no conflict. So the
restriction "unless they are topic items" sounds superfluous to me.

> > - 5.2: Base Locator
> [...]
> >   The only reason can be that the base locator is modified in a TM
> >   instance changing all relative URIs in there. I cannot see any use
> >   case for this.
> 
> Not directly related to TMDM, but how do you identify topic maps
> during a TMQL query? I assume that queries across different topic maps
> are possible. How do you distinguish them?

[I am not sure what this has to do with the base locator.]

To the question itself: Maps can be passed into the query (process)
as parameters, such as a default map. In that case the question is
not relevant for TMQL itself. Using parameters makes a query more
reusable.

Alternatively, a TMQL query can name a map simply using a URI. How this
is resolved may be a local implementation issue:

  for $p in http://topicmaps/samplemap.xtm // person
  return
       $p / bn

or

  for $p in tm://map-cluster/samplemap // person
  ....

> > - 5.3.4 Scope
> [...]
> >   Then why have actually a set there? If it is always the
> >   ANDed set, then the model can be minimalized by everything
> >   having EXACTLY ONE scope and that one scope object then
> >   is a set of individual scopes (just another association with
> >   predefined type and roles).
> 
> While working through \tau I always wondered how I create scope if I
> use the constraint "there may be only one player for a particular
> role" in an assertion. Your proposal may solve this issue.

It would make the transition \tau <-> TMDM less painful. 

At the moment, I model the set of 'scoping topics' as a new topic
(proxy actually) and use that one as a player for the role 'scope'.

Not overly elegant. This whole scoping thing needs to be addressed
more directly.

> > - 5.3.4 Scope
> 
> >   The empty set is the encoding for the unconstrained scope.
> 
> >   I would rather have preferred to have one predefined concept
> >   'unconstrained-scope' and put it as scope if required.
> 
> Something like the "unique topic characteristic" (7.5) technique?

Probably, yes.

\rho