[topicmapmail] Are Facets Really Simple After All?

[Murray Altheim]

Thomas B. Passin wrote:
> I have been thinking that modeling facets could be fairly simple after 
> all, despite the appearance to the contrary in the recent thread "Two 
> Models of Facets".  Here is the idea.  I claim that facets are a way to 
> classify something into multiple hierarchies, as opposed to just one 
> hierarchy.

Tom,

If we use "facet" in the Faceted Classification sense, you have things
in your claim almost exactly backwards. FC doesn't classify things into
a hierarchy, it creates the classification for an entity as the
composite of all of its participations in multiple hierarchies. But in
a sense, it's all just a question of which side of the mirror you're
standing.

[Despite the apparent complexity of the discussion, I don't see that
the basic concepts of either of the two facet models previously
discussed are particularly complicated.]

> For example, say that we have a history facet and a geography facet. 
>  From what I have seen, typically there will be a hierarchy of terms 
> under "geography", such as "location".  That is, the "geography" facet 
> is actually a hierarchical classification tree in its own right.  It 
> just does not try to be all encompassing, but deals only with a 
> Geography-related subset.

Yes, agreed.

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

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.

> You would find out which particular facet tree that 
> "location" is in by walking up to the root of its tree to arrive at 
> "Geography", whose type would be "Facet".  Of course, a real 
> implementation would use some kind of shortcut to avoid actually walking 
> the tree each time.

Perhaps, though I would think traversing a graph shouldn't be too
time-consuming if we're talking strictly taxonomic relations.

> Is there something I am missing here, or is it really this simple?

I think it's probably about this simple. The only added level of
complexity is the idea of constraints, oh, and the alternative
model for property assignment we've been talking about, the "RDF"
approach (Model A in the discussion).

Over the past week or so I've been weighing the pros and cons about
the various ways to assign properties to Topics, and in the end I
think there probably is no right way, that the choice will really
depend entirely upon circumstances and intended use. This doesn't
mean that there shouldn't be a set of PSIs for facets, or some
published best practices for assigning properties to Topics, only
that there might not be such fine distinctions between them.

For example, there's three ways in syntax to assign a characteristic
to a Topic in XTM:

   1. Using an XML processing instruction. This would probably be
      most appropriate to application-specific characteristics or
      aspects that are not really meant to be shared, such as which
      Topics are selected in a visualization, node colour (if there's
      no semantics attached via colour), location in a display, etc.
      But because PIs aren't properly a part of the XML document's
      tree, nor do they have any standardized internal structure,
      any PI approach would have to be considered as both proprietary
      and unlikely to be reusable. But appropriate to some things.

   2. Using a Topic occurrence. I'm leaning towards advocating that
      RDF-style property assignment be handled via Topic occurrences,
      whenever the application doesn't demand or suggest they be
      fully reified as Topics. There's some screwy semantics to doing
      this that I'm not entirely comfortable with, as Topic occurrences
      are occurrences of their Topics, not properties of their Topics.
      So this is breaking a rule IMO, and there'd have to be a typing
      PSI on the occurrence that clearly identified it as not being an
      occurrence of the Topic in question. But this is obviously a
      lighter-weight approach than using a Topic.

   3. Using a Topic. I think this is the only way to accomplish an
      implementation of Faceted Classification in XTM, and it's
      probably the safest and cleanest way too. If the Topic Map is
      reused, the facet Topics are available both as facets and as
      Topics in their own right. The actual markup density isn't
      much different, as <occurrence> isn't much more than <topic>,
      but you would incur the additional Topics in the graph. In my
      own application, I've got a checkbox under Preferences that
      simply hides all facets (i.e., Topics playing a role of "facet"
      in associations).

In terms of simplicity, #2 and #3 aren't *that* much different in
terms of syntax. I like the idea that what is to one Topic a facet
is simply a part of the functional ontology of a larger Topic Map,
that somebody might find the facet hierarchy itself usable/useful
for a different purpose.

I've been looking at storing the color and node location of my
Topic Map visualizations, and it's tough thinking about the pros
and cons of #1-3. What at first seems simple might not be, e.g.,
if my users begin using the colourized nodes as categories and I've
implemented storage of colour as a PI or an occurrence, it'll be
tougher (and kinda ugly) to then begin treating those colours as
topics in searches and other processes. OTOH, creating a separate
<topic> for colour and location for each of the ~700 nodes in the
authoring ontology potentially triples the number of Topics and
Associations in the overall ontology, which is certainly nothing
to sneeze at. Because colour and location aren't truly a part of
the information model of an authoring ontology, using PIs or
occurrences may be the approach I take, though I'm not comfortable
with the misuse of occurrences as properties.

Murray

......................................................................
Murray Altheim                    http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

   "Mr Bush, you have to admit it's a pretty remarkable thing for a
    man just to go to a hotel room door and open it and have a woman
    standing there and have sex with her," said Marshall Davis Brown,
    lawyer for Sharon Bush. "It was very unusual," Bush said.
    http://www.nzherald.co.nz/storydisplay.cfm?storyID=3536318