[heuer@semagia.com: Fwd: Re: [sc34wg3] Feedback on TMDM]

[Robert Barta]

Since Lars' response did not appear yet here:

\rho

----- Forwarded message from Lars Heuer <heuer@semagia.com> -----

This is a forwarded message

From: Lars Heuer <heuer@semagia.com>
To: Robert Barta <sc34wg3@isotopicmaps.org>
Date: Thursday, April 21, 2005 3:44:26 PM
Subject: [sc34wg3] Feedback on TMDM

===8<==============Original message text===============

Hi Robert,

[...]
> - 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. If you create a topic map and merge it with another topic
map the item ids may change but the source locators are stable because
the merged items get the union of both source locator sets.
The id of <topic id="myItem" /> may go away, but I can access the
topic via a source locator "myMap#myItem".

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

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

>   It can be NULL. So what does that mean for relative URIs? Is such a
>   map meaningful?

NULL may be an issue. :)

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

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

Best regards,
Lars
-- 
http://semagia.com

===8<===========End of original message text===========


----- End forwarded message -----