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

[Graham Moore]

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.

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

----------------------------------------------------------------
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:
>=20
> FACT: 2 different URIs can reference the same resource.
>=20
> 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 =
collection.
>=20

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

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