[topicmapmail] Are Facets Really Simple After All?

[Thomas B. Passin]

Dan Corwin wrote:

> * Thomas B. Passin wrote:
> 
>>> If this is a reasonable way to look at facets, then I do not see
>>> why using facets would be different in any essential way from
>>> classifying using a single hierarchy.  A given topic could be
>>> related to one of the faceted terms, say "location", by an
>>> association called, perhaps, "hasFacet".
> 
> 
> * Murray Altheim wrote:
> 
>> So far I think we're in complete agreement. E.g.,
>> 
>> hasFacet([Paris] : faceted, [France : location] : facet)
>> 
>> Choosing to model the "is in" relation above as a facet vs. simply
>> using a direct relation is simply a matter of how one desires to
>> model the classification scheme.
> 
> 
> Murray and Tom -
> 
> The above example looks easy, but if you needed to *also* model "is
> on", "is under" and a few other spatial relations as facets, what
> would you change to let them logically coexist in a single TM along
> with "is in"?
> 

Well, you should be creating your facets judiciously.  They are supposed
to help you classify or find information, and too many facets are likely
to be unhelpful.  If I found a need to have a complex and structured
property as a candidate facet, I would think twice about whether it was
suitable to be a faacet at all.  Here, I am thinking about  a "location"
facet - or candidate facet - that might include lots of those
properties, such as -

location = {lat/lon, on, under, beside}

Up to now I have not been thinking about "facets" as they are used to
describe data types in W3C XML Schema, but facets as they seem to occur
in library science.  I have not thought about it much but I am not so
ure that the two senses of the term are equivalent.

It seems to me that a collection of facets such as are used to describe
one of those data types is similar to a row in a database.  This is a
different kind of model, one which can be done very nicely with ordinary
associations - one per row  where one row represents one datatype, or in
this case, one per collection of "facets".

> One option I see is to duplicate, for every new facet, the Java 
> access code and/or PSIs which are being used:
> 
> http://www.altheim.com/ceryle/api/org/ceryle/tm/Facet.html
> 

I would like to arrive at a decent, easy to understand model before
thinking much about implementation.  There is nothing to stop an
application from implementing some of these structures differently from
ordinary topics and associations, as long as the behavior ends up as
prescribed, so the implementation of facets could be radically different
if needed for efficiency.

> When you agree it is "really simple", are you factoring these 
> alternative dependencies (code duplication or tolog) into your 
> conclusion, or do you see some simpler way I am missing to let you
> handle multiple facets in one TM?
> 

I am only thinking of static topic map design, but I do not see why 
there should be any more of a problem with multiple facets than with one 
facet, any more than there would be some reason to avoid more than one 
kind of hierarchy in a topic map.

Cheers,

Tom P