[sc34wg3] TM Data Model issue: prop-subj-address-values

[Kal Ahmed]

On Fri, 2003-10-31 at 08:40, Geir Ove Grønmo wrote:
> * Kal Ahmed
> | On Thu, 2003-10-30 at 21:54, Geir Ove Grønmo wrote:
> | > I _might_ consider http://example.org/, http://example.org/.,
> | > http://example.org/foobar/../, http://example.org/nodes.py?id=root,
> | > http://example.org/index.htm, http://example.org/index.jsp and
> | > http://example.org/index.html all to reference the same resource even
> | > though they are different locators. Not sure, but this issue may boil
> | > down to whether or not the same _resource_ can be referenced by more
> | > than _one_ URI. This depends on our definition of what a _resource_
> | > is.
> | 
> | I think that is the key point. The definition of resource is not a
> | clear-cut thing (not even the relevant RFCs, standards, and TAG
> | pronouncements seem to match on this). Also there is the issue of what
> | is a URI - are two URIs equivalent if the resolve to the same resource?
> | And then you get into a circular trap...
> 
> I found the following message, which should be of interest in this
> discussion:
> 
> http://rdfweb.org/pipermail/rdfweb-dev/2003-August/011820.html
> 
> RFC 2396 (URIs) does seem to indicate that different URIs can reference
> the same resource. 
> 
> | > | If you were to allow multiple subject locators, you would not only
> | > | allow the arguably correct case of two locators which return the same
> | > | resource, but also a whole raft of incorrect cases where the two
> | > | locators return different resources. [subject locator] is the lesser
> | > | of these two evils.
> | > 
> | > If it is incorrect -- then it is the _authors_ fault. No more no
> | > less. If it is incorrect - that's a human being's fault. Shit in - shit
> | > out etc. That's life.
> | 
> | No, consider mirrored sites - site A is mirrored by site B, such that
> | each URL x on A is mirrored to URL x' on B. Most of the time a URL x'
> | resolves to exactly the same sequence of content bytes as URL x. But
> | when the resource at x is updated, there is a lag before x' is
> | synchronised again. So a topic with x and x' as subject indicators
> | sometimes represents one resource and sometimes represents two
> | resources.
> 
> Is inter-site mirroring any different from intra-site mirroring? ;)
> 
> | > Why would we not want to trust topic maps authors?
> | 
> | Its not a question of trust, its a question of the model that we have for 
> | URIs, resources and subjects and the particular set of heuristics that we
> | choose. I feel that the original heuristics encoded in XTM 1.0 are right - 
> | one locator, one resource, one subject.
> 
> I see this as a matter of whether we should let authors express the fact
> that a subject, that is an information resource, can have more than a
> single locator (e.g. URI) referencing it or if we should force the topic
> map processor to choke if it so happened that two different authors were
> using synonymous locators. I have difficulties seeing the usefulness of
> that.
> 

But there is nothing to stop the author creating a topic that represents
the resource and adding occurrences indicating where it is mirrored or
alternate access points to it. Equally, there is nothing to stop a topic
map application that want to, from processing occurrences of a
particular type as providing subject identity and doing merging on that
basis.

Having a topic map model that says one locator, one resource, one
subject is useful as it provides a concrete model that people can work
with rather than "Oh you have a topic with multiple subject addresses,
well they could all be the same resource or it could be a mistake, I
don't know, you had better get the resources and check for yourself".

Cheers,

Kal