[topicmapmail] Are Facets Really Simple After All?

[Kal Ahmed]

On Mon, 2003-12-01 at 18:53, Miles Thompson wrote:
> Murray Wrote:
> 
> >> ..the idea  of being able to express simple triples 
> >> about a Topic without invoking  the whole Topic machinery
> >> is what I have heard people yearn for since 
> >> we did XTM (and during its development).
> 
> Kal Ahmed wrote:
> 
> > The reason facets didn't make it into XTM was that it was felt that if
> > this resource is something you care about enough to want to attribute
> > property/value pairs to it, then you should create a topic that 
> > represents that resource and use occurrences. In other words,
> > ISO 13250:2000 facets are a short cut for reification and using
> occurrences.
> 
> So. My question is this..
> 
> Are there any semantic characteristics of facets (represented in some
> property-value form) that could not *conceivably* be represented by some
> construct as 'occurences' (that is, either of the subject represented by
> the topic or of the topic itself ) ?
> 

Thats a good question. My opinion is that there is nothing that can be
represented by a facet that cannot be represented by a combination of a
topic and occurrence.

> Seems to me, that if the answer to the above question is 'none, really',
> then its reasonable to consider facets as 'occurances light' that is,
> 'short cuts'.
> 

That would be a good position. Though as I mentioned, you still have
this fiendish mnemonics problem if you want to handle the full-blown ISO
13250 Hytime-based architecture.

> Now. Don't get me wrong here, I think that short cuts and
> simplifications are important. [ I simply don't buy the argument that
> you can construct a perfect 'model' with no regards for implementation
> issues - in my opinion this is one of the things that went 'wrong' with
> the VRML standard, and what caused it to be so ungainly and have such
> slow uptake. ]
> 

Shortcuts and simplifications can be useful. But I dont' think that we
are in the position with the topic maps data model that it is a
VRML-monster. Its quite easy to read and dead easy to implement naively
(trust me, I know ;-) Hence my exhortation to optimise at the
application layer, not at the model layer.


> So... if the suggestion to include facets back into XTM can be thought
> of as about making certain types of things 'easier' to represent. Then
> we could potentially work backwards, and ask, what are the things that
> occurances do, that we consider to be ungainly or too heavy for
> representation of things like 'topic creation time' or dublin meta data
> etc.
> 
> That is, could one work backwards and define the things that we would
> want facets *not* to do (versus Occurances) ? 
> 
> Could we even define that a facet is a type of occurance, but with
> certain assumptions made vis-à-vis how datatypes (XSD), topic-type
> hierachies etc operate?
> 

I think that if one were to add facilities to a reintroduced facet
structure, you would have to add the same facilities to occurrences (I
am thinking here of data-typing as a prime example). If you didn't, then
people would not understand why they can do something when they attach 
a simple property-value pair to a resource, but not when they go all out
and create a topic that represents the resource and add occurrences to
it. And if you did add the same facilities to occurrences as you have on
these new facets, then you are back to the position that you have a
perfectly good (topics + occurrences) system for expressing what you
want to express. So why add another construct to the model ?


Cheers,

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