OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xtm-wg] Re : Topic Naming Constraint


I fully agree with Kal, and consider it a *very* important point to be
settled.

I wonder how the conflict will be resolved when a merging process meets two
Topics with identical <baseName> but obviously semantically incoherent
<subjectIndicatorRef>. In fact the conflict will not declare I suppose, but
the risk is to get incoherent content under two or more
<subjectIndicatorRef>. In fact I don't understand why a Topic should be
authorized to have *more than one* <subjectIndicatorRef> element. Should
not the <subjectIndicatorRef> be an unique and non-ambiguous identity
basis, not only for merging ? It seems more semantic-consistent to gather
different names around a subject well defined through a (never ambiguous)
URI, than risk to gather inconsistent subjects around a ( almost always
ambiguous) name.

It's in fact a crucial choice between a "conceptual" or "objective"
approach of  Topics identity.

The "conceptual" approach is : build Topics identity around subject names,
start from concepts and gather objects - occurrences - around them. That's
what most web directories do. This approach is bound to lead to
inconsistencies most of the time. Worst of it, machines process that
without noticing these inconsistencies - but end users do !

The "objective" approach is : build Topics identity around subjects
*defined by resources* - in fact constrain subjects to be addressable or
have an addressable proxy. This approach I think leads to define more
accurately subjects and avoid "fuzzy merging".

The problem raised by Kal points to the fact that the present specification
allows coexistence of the two approaches. I don't think it's sustainable,
and clearly favor the "objective" viewpoint, for all purposes, even for the
most "conceptual" contexts - and maybe more for those, where ambiguity is a
permanent risk. The only drawback I can find in that position is that it
does not allow to build "purely conceptual maps" with no occurrence and no
subject indicator reference at all - representation of semantic networks
for example -  But this drawback seems a minor one, since most applications
will concern mapping of "real" resources.

---------------------------------------
Bernard Vatant
bernard@universimmedia.com
www.universimmedia.com
"Building Knowledge"
---------------------------------------



To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC