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

Graham Moore sc34wg3@isotopicmaps.org
Mon, 3 Nov 2003 15:07:02 +0100

Kal wrote:

>> FACT: 1 topic can only represent one subject

No, 1 topic *should* represent one subject but as we know the SLUO is =

>> FACT: 1 resource is one subject=20

Indeed but that doesn't matter.

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

Graham Moore, Ontopian            moore@ontopia.net
GSM: +47 926 82 437           http://www.ontopia.net

-----Original Message-----
From: 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=20
> current draft states that it is an exception if the topics being=20
> merged have different values in the subject address property. From=20
> above it follows that this is an unsafe assumption. Thus to support=20
> this fact, this non-determinism, subject address should be a =

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 =

> Let me also position things in terms of a more general principle taken =

> from the use and expectations of subject identifiers. There is no=20
> reason why two subject identifiers cannot indicate the same subject=20
> via different indicators. It is desirable to have one and only one,=20
> 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=20
> 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=20
> has triggered it then we dont throw an exception if the two topics=20
> have different subject identifiers because thats the way it works.=20
> 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=20
> ambiguity/ flexibility.

I think you are comparing apples and oranges here. Subject indicators =
URIs of resources that describe subjects, and a subject can be
*described* by many resources. So there is, in my mind, no parallel here =


Kal Ahmed, Techquila
Standards-based Information Management
e: kal@techquila.com
w: www.techquila.com
p: +44 7968 529531

sc34wg3 mailing list