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

[Kal Ahmed]

On Mon, 2003-11-03 at 14:07, Graham Moore wrote:
> Kal wrote:
> 
> >> FACT: 1 topic can only represent one subject
> 
> No, 1 topic *should* represent one subject but as we know the SLUO is not
> achievable.
> 

So we should abandon the only remaining heursitic in XTM that comes
close to the SLUO ?

> >> FACT: 1 resource is one subject 
> 
> Indeed but that doesn't matter.
> 

It does when taken together with the preceding fact.

> Both subject identifiers and subject addresses are means of establishing
> identity. There is no guarentee of correctly determining (when the URIs are
> different) whether they are representing the same subject. So I think the
> comparison is a useful one and gives good guidance as how we should proceed.
> 

No, a subject indicator has a completely different semantic to a subject
address. A subject indicator tells you that a resource describes the
subject of a topic, not that it is the subject of a topic. They follow a
heuristic which says that "well constructed and well chosen subject
indicators will always convey exactly the same subject to the intended
audience of the topic map" - otherwise they don't work. Subject address
on the other hand says "the resource at this address *is* the subject".
There is no concept of interpretation of the resource in the semantic of
subject address. The only similarity is that both properties use
locators. Thats it. They use locators in different ways with the
addressed resources have different relationships to the subject - so I
don't see how any useful comparison can be made.

Cheers,

Kal


> ----------------------------------------------------------------
> Graham Moore, Ontopian            moore@ontopia.net
> GSM: +47 926 82 437           http://www.ontopia.net
> 
> 
> -----Original Message-----
> From: sc34wg3-admin@isotopicmaps.org [mailto:sc34wg3-admin@isotopicmaps.org]
> On Behalf Of Kal Ahmed
> Sent: 03 November 2003 14:54
> To: sc34wg3@isotopicmaps.org
> 
> On Mon, 2003-11-03 at 10:39, Graham Moore wrote:
> > Ok, heres my take:
> > 
> > FACT: 2 different URIs can reference the same resource.
> > 
> > When merging topics based on, for example subject identifiers, the 
> > current draft states that it is an exception if the topics being 
> > merged have different values in the subject address property. From 
> > above it follows that this is an unsafe assumption. Thus to support 
> > this fact, this non-determinism, subject address should be a collection.
> > 
> 
> FACT: 1 topic can only represent one subject
> FACT: 1 resource is one subject
> 
> So I think you have an even worse conflict if you let subject address be a
> collection.
> 
> > Let me also position things in terms of a more general principle taken 
> > from the use and expectations of subject identifiers. There is no 
> > reason why two subject identifiers cannot indicate the same subject 
> > via different indicators. It is desirable to have one and only one, 
> > but that is unlikely no matter how hard we try. But we dont say in the 
> > standard that to have two subject indicators is an error. i.e. we err 
> > on the side of flexibility because we can't be sure. If two topics are 
> > merged because a name match has triggered it or some application code 
> > has triggered it then we dont throw an exception if the two topics 
> > have different subject identifiers because thats the way it works. 
> > Thus, I dont see a big distinction between supporting a scheme we have 
> > defined (Subj Inds) and a scheme that exists
> > (URI) as being different when in both cases there is a degree of 
> > ambiguity/ flexibility.
> > 
> 
> I think you are comparing apples and oranges here. Subject indicators are
> URIs of resources that describe subjects, and a subject can be
> *described* by many resources. So there is, in my mind, no parallel here at
> all.
> 
> Cheers,
> 
> Kal
> --
> Kal Ahmed, Techquila
> Standards-based Information Management
> e: kal@techquila.com
> w: www.techquila.com
> p: +44 7968 529531
> 
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
> 
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
-- 
Kal Ahmed <kal@techquila.com>
techquila