[topicmapmail] Redefining the Facet

[Murray Altheim]

Dan Corwin wrote:
> Lars - 
> 
> Thanks for the feedback.  I'm still wrestling with what specs
> define what concepts, and N323 was very helpful here. 
> 
> I'm not really hoping to change how people speak, but to advocate
> some modeling techniques I associate with facets in their AI/KR 
> sense, which is outlined very briefly in [1]:
> 
> [1] http://babs.cs.umass.edu/research/frame-system/section1_2_0_2.html
> 
> These techniques would let XTM 1.0 readily record several common 
> sorts of constraints, including those of [2], [3] and [4]:
> 
> [2] http://www.ai.sri.com/~gfp/spec/paper/node22.html
> [3] http://www.w3.org/TR/xmlschema-2/#facets
> [4] http://kmi.open.ac.uk/psi/datatypes.html
> 
> Using these techniques in a TM requires one to notice, and then to 
> somehow formalize, this rough analogy:
> 
>   an AI/KR frame is an open set of slot-value pairs (like a topic)
>   an AI/KR slot resembles the type of an XTM occurrence or role
> 
> The potential benefit is a TM-specific version of this paradigm:
>  
>   an AI/KR facet constrains the legal values of data in a slot
>   an AI/KR facet is stored in a frame modeling the slot itself

Thanks very much for the references -- my early attempts at
"converting" the Cyc ontology would have benefited from this,
but at the time I was pretty ignorant of such things.

My own approach was not to pay so much attention to occurrences,
using the topics-and-associations graph structure more the way
it's done in Conceptual Graphs (and indeed, at one point was
trying to figure out how to model CGIF in XTM; I'm now waiting
for CL/CLML to be published and stabilize).

> The combination suggests XTM might easily store any constraint 
> such as [2]-[4], for some value V, in the topics cited within:
> 
>    <instanceOf> the <occurrence> holding V (at least for [3],[4])
>    <rolespec> of the <member> citing V (for type-[2] constraints)
> 
> In my own ontology, I find it convenient to generalize these two
> types of slot-like topic into a single "aspect" superclass, which 
> I then partition back into groups by adding facet-like occurrences 
> that summarize each aspect's expected data type:
> 
>    group 1 - takes <resourceData> as expected scalar value
>    group 2 - takes <resourceRef> as expected URI value
>    group 3 - takes <topicRef> as expected member value

This makes good sense, and is essentially the same approach I
was taking.

> To get more specific on data types, I'd simply add a new AI/KR 
> facet to the related aspect sub-class, one which (by convention)
> further restricts legal values for all that aspect's instances.
> 
> For group-1 aspects, I might cite [4]'s PSIs.  Groups 2-3 
> would today take something more ontology-specific.  To take 
> Murray's notion further, it could be application-specific PSIs.
> Or perhaps an expresssion written in TMCL, OWL, or even XSD.

I'd very much appreciate an example of something you consider
"more ontology-specific". I've sorta chosen Nicola Guarino's
approach to ontology (in general), so for my own ontology work
the foundation is typically a taxonomy-mereology, with "affinitive"
and "associative" relations layered "on top" (the latter terms
pulled from faceted classification ala Ranganathan).

> Key point #1:  Such facet-like data takes no defining of general 
> new structures for XTM, but merely the central addition of a new 
> facet-like occurrence or association to the *specific* slot-like 
> aspect sub-class(es) directly involved.  Unchanged XTM storage 
> (and merging) rules should handle all of this data just fine.

Agreed, and an important point -- we don't need new syntax to
"do" ontologies in XTM.

> Key point #2:  An application, which must enforce the implied 
> rules, gets a simple, general method for finding them: look up 
> the related aspect topic, then dispatch to group-specific logic
> exploiting its facets to validate a given value, find a default
> value, or perform other actions in an aspect-specific mannner.  

And this can be relatively easily done in a domain-specific manner.
This approach can also be taken for alternate AI/KR metaphors, too.

> Recently, this list was debating where to store topic properties.
> Do aspect topics (and their AI/KR-type facets) seem good places 
> to centrally store their related constraints and meta-properties?

For the kind of work I'm doing this seems the best approach, but
I think we might also consider these as "facet topics" for the
more general Topic Map applications that aren't in the realm of
AI/KR. They sound like synonyms to me, but it's probably safer
to define this as a general solution, then as a solution for
specific domains. The terminology (and thus the PSI sets) will
likely be different for every application domain, and there are
a ton of them.

Murray

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

     "In Las Vegas Mr Gates also demonstrated a prototype
      fridge magnet which can be programmed to receive traffic
      reports, sports results and advertisements from local
      restaurants using the same FM signal as the wristwatch."
                                  -- The Guardian, 10 Jan 2003.