[topicmapmail] Are Facets Really Simple After All?

[Thomas B. Passin]

Murray Altheim wrote:

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

I think that, in you remarks a bit later, that you picked up on my 
thinking, namely, that each facet can be elaborated into its own 
separate hierarchy.

> So far I think we're in complete agreement. 

Excellent!

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

Right, I just meant that the means would be implementation-dependent, so 
as not to get caught up in the putative efficiency of different 
representations.

>> Is there something I am missing here, or is it really this simple?
> 
> 
> I think it's probably about this simple. 

OK, thanks.

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

I agree with this completely.


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

Same here.  There should be a light-weight way to assign type/value 
pairs, and the occurrence is all we have at the moment.  I would 
actually like to be able to use topics as the target of occurrences as 
well - that would be more RDF-like, too.  Of course, if we end up always 
representing occurrences as associations, this would just be syntactical 
sugar, but still ...

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

Well, we can already use literals as the referent of an occurrence.  The 
occurrence would then seem to be saying "Here is some information of 
type [xxx] about the topic".  That is not really much different from 
saying "property", I don't think.  When the referent is a retrievable 
resources, I agree that it seems a bit different, but you could argue 
that when the resource gets retrieved, you simply have retrieved the 
value of a literal, and so there really is not any fundamental difference.

I don;t think that it too hair-splitting, do you?

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

D'accord.

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

D'accord.

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

Yes.  If you want to exchange graphs and have them layout the same way, 
you have to persist the layout information somehow.  And good layout is 
very hard to arrive at, whether automatically or by hand, so it is 
desirable to save it.  I am interested in sharing layed-out models, so I 
do not favor using PIs.

 >
> 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, 

But layout can be crucial in helping the reader to understand.  For 
example, layout of an electronic circuit diagram can be critical for 
understanding, even though it makes no logical difference.  So layout is 
not always entirely divorced from the informaton content.

> using PIs or
> occurrences may be the approach I take, though I'm not comfortable
> with the misuse of occurrences as properties.
> 

There is another possibility.  We could have an XML standard or 
convention for interchange of layed-out topic maps. The layout data 
could be stored in non-topic map elements separate from the topic map, 
which would be embedded in the document, or we could create a PSI for a 
pointer to the separate location and format of the layout data.

Cheers,

Tom P