[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