[topicmapmail] Are Facets Really Simple After All?

[Murray Altheim]

Thomas B. Passin wrote:
 > Murray Altheim wrote:
[...]
 >>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 ...

I don't see that there's any reason why you couldn't have a Topic
referenced as an occurrence of another. You'd just have to make sure
to use the correct reference type. If you used <resourceRef>, you'd
be really devolving the XTM syntax down to an RDF-like thingie. I
don't know how many TM applications would know what the heck to do
with it though. I doubt many would interpret it correctly.

 >>     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 literals as Topic occurrences necessarily entail anything
different than a reference. Either can conform or abuse the concept in
the same way. I commonly use an occurrence's <resourceData> as a local
description of the Topic (which isn't metadata about the Topic in the
same way as creation date is; I'd say this is closer to my interpretation
of "is relevant to" in the standard).

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

Well, hair-splitting to one person is an axe through a log to another.
I apparently feel much more strongly about what I've been calling
"semantic violence" (or some such thing) than does Kal. It's not that
he's right and I'm wrong or vice versa. I think the Topic Map paradigm
permits both of us to be right. It's a modeling paradigm and we simply
have different models. Mine is stricter about what constitutes a Topic
occurrence, and I *hope* to stick to that as much as possible.

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

Oh, I quite agree. In fact, Jack Park has been interested in using
Ceryle for display of Conceptual Graphs. Well, there's no need in
CG for the dynamic TouchGraph display, which would be destructive
to the user experience. In some instances, if a user colours something
red and puts it at x,y, they expect it to come up red at x,y until
they change its colour and location again.

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

Essentially, a stylesheet for Topic Maps. The big problem I see with
this is that of all of the commercial and non-commercial Topic Map
visualizations I know of, no two really have the same display paradigm,
so I don't think this would work. And as I've mentioned in a previous
message, I think we need to look at this problem more generally than
just UI stuff, and solve it in the main.

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