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

[Kal Ahmed]

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