[topicmapmail] Two Models of Facets

[Murray Altheim]

Dan Corwin wrote:
> * Murray Altheim wrote:
> 
> 
>>I'm quoting from:
>>
>>  Two Models of Facets, Murray Altheim, 18 Nov 2003
>>  http://www.infoloom.com/pipermail/topicmapmail/2003q4/005406.html
>
> Gotcha.  But FYI, I'm still unsure what "Model-T" signifies beyond
> a pattern that has attracted a lot of interest.

What part is unclear? Model A is essentially RDF's method of attaching
a typed property value to an entity. Model T is the Faceted Classifi-
cation model of capturing the emergent subject identity of an additive
set of facets. This is described in more detail in the cited message.

>>For purposes of discussion I'll delineate two kinds of Topics, class
>>Topics and instance Topics. And we'll call (for purposes of discussion)
>>"properties" the things attached to instance Topics, and  "facets" as
>>the things assigned to class Topics (we'll see if this pans out; if
>>not I'll drop it). I'll also try to remember to capitalize "topic" when
>>I mean Topic Map Topics. I'll use "characteristic" when I am being
>>deliberately ambiguous about whether something is a facet or a property.
> 
> I'm far less sure what "facet" signifies, so I'll use "charateristic".

So you don't care to for the purposes of this discussion allow me to
define a term. Okay. "Characteristic" is perhaps more generic. There's a
lot of possible words, but they all have overtones.

But I think in order for us to communicate, we're going to have to
arrive at a set of agreed-upon terms (a shared vocabulary), and I'm
not trying to be a dictator here. You can state an alternative. But
don't leave a criticism of my terminology hanging without doing so;
we need *some* word to describe things. I don't want to use "x-foo"
or "A" or "T" really. Words are symbols, but I'd rather use words
than symbols, literally. And I hate neologisms, which force people
to either use them or not. I suppose that's the way it is with any
agreed-upon vocabulary.

>>Now, one aspect of this I don't like necessarily is the implied rule
>>that one wouldn't assign a facet to an instance, or a property to a
>>class. But I am meaning to say that there are things that are
>>characteristics of all members of a class, and there are characteristics
>>that are meant to be assigned to a single individual. Now, without going
>>too far down the extensional/intensional waterslide, I'll use an
>>example.
> 
> I do recognize that classes and instances demand two very different
> approaches to characteristics under a data-inheritance paradigm, at
> least for characteristics modeling a part (such as "blue eyes").

I'm going to use your choice of "part" later, without thinking of
any part-whole relations. (for me, that's hard)

>>We could say that Jim has blue eyes. Are the colour of Jim's eyes a facet
>>or a property?
> 
> Probably yes - one or the other  :-)
> 
> But I am quite sure they are a part of Jim, so I know he cannot inherit
> them from his class without some sort of intermediate mechanism.

Jim as an individual doesn't "inherit" anything. He's an instance of
the class of "human", so he's really "instantiating" those properties.
Only classes inherit things. Unless we want to relax that definition
as well. (I'm not talking about Jim inheriting his blue eyes from
his mother, which is a different usage and domain of discussion.)

>>If in our model it's important we'd be better off creating
>>a "proper" Topic for eye color and creating a "proper" Association with
>>it to its faceted Topic. We're assuming there's some value in dealing
>>with this as facets or properties, namely the value of Faceted Classifi-
>>cation in the former, the ability to add scalar properties to a Topic
>>in the latter (basically what RDF does).
> 
> A part *cannot* be simply inherited from a class to its instances, as
> instances *must* have parts which are also instances, and unique.

Since I don't agree with inheritance from classes to instances, I'll
try to read this as what I think you're saying, which is that you're
essentially agreeing with me about instantiation vs. inheritance. That
we are in agreement.

>>We could classify people by their eye colour, hence we'd have created
>>a topic of "blue eyes", just as we could create a class of "people who
>>are 5'7" tall. But *normally*, we think of eye color or height as a
>>characteristic of an individual. This will always to some degree come
>>down to the purpose of the characterization, as should any modeling or
>>ontology.
> 
> Except for ids, most other characteristics can be inherited.  In
> particular, categorizations can be (presumably, even if "faceted").
> 
> So in my book, Jim *can* easily inherit the "blue-eyed person"
> characteristic.  But not one which directly models his two blue
> eyes per se.  That would be too detailed, and lead to nonsense.
> At best, he can inherit *a copy of* some general prototype eyes.

Again, I'd say that if we avoid the usage of "inheritance" in terms
of genetic inheritance (perhaps we'd have been better off with a
different example), Jim doesn't inherit his eye color, his eyes are
an instance of "eyes" which have the property of "blue". I don't
quite understand what you mean about something being "too detailed",
or inheriting a "copy". Again, the inheritance vs. instantiation,
maybe?

>>If we assume that for the purposes, "having two eyes" is a property of
>>Jim as a human, and "having blue eyes" or "being 5'7" tall" is
>>properties of Jim and not all humans (a simple rule of thumb, then I'd
>>consider the former a facet and the latter as a property. Facets are
>>used to delineate subjects, properties provide meta-information about
>>a specific individual (as a subject, since everything we're talking
>>about here is a subject-reified-as-a-Topic). Like I said, all cautions
>>here apply.
>
> We seem close to agreement on some key concept lurking here.  But I
> don't buy your terminology.  Sorry.

I could be very nerdy and quote Morpheus from the Matrix, but I won't.
I'm not asking you to buy into any terminology. I'm suggesting a
terminology in order to discuss the difference between various concepts
that are confused/confusing. If you don't like my terminology, I can
only suggest you suggest an alternative, because the only way we can
communicate unambiguously is to agree upon a set of terms for the
purposes of discussion. There's no long-term commitment here. If we
don't agree to use a common terminology, we are going to have to end
trying to resolve this. And of course, it's usually in the process of
arriving at a shared vocabulary that many issues are resolved.

This is at least the way I usually try to work. Otherwise we're sunk.

> FYI: I view "property" as meaning "typed string" (inheritable unless
> the specific type definition somehow precludes that).

What about properties that aren't strings? Like eye color? I don't
follow this statement in this context, given the earlier discussion.

> I view "facet" as hopelessly overloaded.  Its use only confuses
> things, as it has *several* good definitions out there, all
> competing, each of which with advocates who will never fully
> buy into yet another redefinition.
> 
> So its use is ultimately divisive, IMHO.

I'm ultimately hoping to not describe a *new* definition, but come to
an agreement about which of the available definitions fits with each
of the uses in Topic Maps, and then move on from there. So far as I
understand, none of the definitions I've provided are new nor are they
in conflict with existing ones. I just chose from amongst the ones
available. The usage in ISO 13250 is unspecified as to which "facet"
is meant. I'm trying to clear that up. We already have "facet" in
Topic Maps, and it's from what I can tell not an existing definition
(well, prior to publication of the standard).

> * earlier dialog:
> 
>>>1) Relative to model-A, a psi-tree seems to define an enumerated data
>>>type, one node of which (its PSI) can be selected as the characteristic
>>>of some topic - lets call it X - that you want to model.
>>
>>So basically, you're talking about a property-value pair being added to
>>an instance topic (as opposed to a class topic), and that the property
>>type is part of a hierarchy.
> 
> I would let model-A characteristics describe either.  And by default,
> they would inherit from the class to each instance.

This would lead to modeling errors, as Peter has shown recently
in thinking of "lifespan" of a class as the same as the "lifespan"
of an individual. Same word, same basic definition, completely wrong
in mixing them up. We want to avoid that if at all possible. This
is precisely the kind of mistake I see all over the place in almost
all of the documentation of the "Semantic Web" (i.e., mixing up
classes with instances, inheritance with instantiation, properties
with facets (using my definitions), etc.). This is why reification
in RDF was messed up. I realize people aren't usually that precise
in discussion, but it certainly matters when you start talking about
doing inferencing and reasoning on things. Transitivity errors are
the first, with many more to follow.

>>[I wouldn't necessarily think the data type had to be enumerated,
>>unless by that you mean that the type is itself defined by a selection
>>of types from up and down a hierarchy, which I think is a bit strange,
>>so I'm guessing you don't mean that -- an example of this strangeness
>>might be "Jim has _____" where the slot filled in is "two eyes" and the
>>hierarchy has something to do with body parts.]
> 
> A Model-A can hold any string, but it only has meaning when you give
> it a type (format, significance, etc.)  "Jim has {string}." says nothing
> formally, except to humans who can (mis)interpret "{string}".

Okay, understood. If we're only talking about strings. But yes,
properties need types.

> A node in a PSI-tree is one kind of meaning you might assign.  And
> yes, I do think that is often helpful - precise, compact, simple.
> 
> Other types could be "a numeric measure of some property in known
> units", "formatted string signifying {some code or id like a SKU}",
> or any XSD basic data type - "dates", etc.

I think to some degree perhaps you're mixing the issues surrounding
markup (which is the serialization of concepts and their relations)
with the model we're talking about. I'd like for purposes of
discussion to either stay talking about markup or stay talking about
models. PSIs are irrelevant to the model, they're just a way of
referring to a Topic/topic.

>>>2) You can expand the psi-tree into an equivalent structure of topics
>>>and associations, one node of which (topic for its PSI) can be used
>>>in the same way to model X.
>>
>>I don't want to bog us down in PSIs. They're just stand-ins for stable
>>Topics. So the tree you're talking about is a hierarchy of Topics from
>>which one is plucked to act as a property for a Topic, which I've been
>>calling the "faceted" Topic, as opposed to the "facet" Topic.
> 
> PSIs to me are public definitions.  If you added one to your "facet"
> topic, I'd know what it meant, and how to interpret its association
> to your "facted" topic.  Drop the PSI, and I generally don't.

PSIs aren't definitions at all. They're just URIs. They *indicate*
a subject; they're not the subject. If we stay talking in the markup
we can keep talking about PSIs and <topic> elements, but really I
think we need to be talking up in the model where the meaning is.

I do understand what a PSI is, and that we can share a concept via
a PSI. But really what we're doing is coming to an agreement (i.e.,
an "ontological commitment") that a term or definition is shared
between us, then using the PSI to indicate the Topic expressing
that subject.

> Unless of course, the association itself were defined, perhaps by
> a different kind of PSI, or I make a lucky guess based on spelling.

We'd not want machines to be doing that. I don't want my bank, the
local airport, or the FBI making inferences based on lucky guesses.

>>>I do not think (1) and (2) are equivalent, but they do seem very
>>>similar from a functional view (especially as seen by X).
>>>
>>>Meanwhile (2) is not equivalent to your Model-T characteristic of
>>>X, but it also seems very similar.  
>>
>>I think this is where I'm losing you a bit. If we ignore PSIs for a
>>moment and consider only that any property is likely part of a larger
>>hierarchy of characteristic, then okay, I agree. But "very similar"
>>here in what light?
> 
> Given a PSI-tree, you can declare a topic for each node it holds.  To
> do so adds no characteristics, but only makes them easier to add.
> 
> In particular, you can now relate the "facet" topic to the "faceted"
> topic by using an association (my model-2) instead of an occurrence
> (my model-1).   So what?
> 
> Except for extra storage bits and added flexibility, nothing seems
> gained.  So models 1 and 2 seem semantic equals.
> 
> How would you exploit the extra flexibility in Model-T?
> 
> 
>>Any assignment of characteristic might be considered
>>similar, but Models A and T are (I hope) fairly clearly different. The
>>former is (to use today's parlance) a property of an instance Topic (or
>>individual), the latter is a facet of a class Topic.
> 
> 
> The first assertion is what we're discussing.  Except for bits and
> flexibility, *how* do they differ?
> 
> If the second assertion is your answer, I think it's off track in
> two ways: it changes existing technical definitions for words; and
> it omits the influence of parts in modeling classes & instances.
> 
> 
>>>So maybe there is a spectrum
>>>of similar things, whose differences at each stage we might try
>>>to further clarify:
>>>
>>>   Model-A
>>>   Model-1 = Model-A with psi-tree doc
>>>   Model-2 = Model-1 with topics added
>>>   Model-T
>>>
>>>To me, the biggest changes lie between model-A and model-1: the
>>>PSIs which declare the occurrence to be an enumerated data type.
>>
>>Well, I have to kinda translate what you're saying, removing "PSI"
>>and inserting "Topic". A PSI is a URI label for a Topic. 
> 
> 
> That is precisely the (small) difference I see between models 1 & 2.
> 
> 
>>So we have
>>a tree/hierarchy of Topics that may be used as types for properties.
>>By "enumerated" I'm assuming you mean to also include "scalar"?
> 
> 
> I usually picture a small set of options - but SKUs could easily
> number 20,000.  Either way, such a type demands a *selection*
> 
> If by "scalar" you mean integers, I'd see them as a *count* or
> *measurement*, not as a classification mechanism.
> 
> 
>>>But I am still fairly confused about model-T.  If you added psis,
>>>how do you see the result differing from model 2?
>>
>>Because Faceted Classification (in the formal sense) relies on a
>>hierarchy of facets (or facet Topics, in our case), both the
>>A/property/instance/RDF and T/facet/class/FC models may have a
>>complete hierarchy of Topics behind the scenes providing an
>>inheritance chain of properties and facets, so from an entity
>>"human" we can transitively infer (via its facets) "mammal",
>>"animal", "living thing", "temporal thing", etc.  This applies
>>whether we're talking about properties or facets. So yes, they
>>do share this idea of a hierarchy. I think both semantically
>>and epistemologically this must always be the case.
> 
> 
> Sorry, but I was hoping to find out how your Model-T differs from
> my model-2.  You seem to be saying how they are alike.
> 
> Except for (a) my PSIs, (b) our terminolgy, (c) your unqualifed
> class-instance distinctions versus my qualifications on parts,
> I see them as congruent.

Well, I see terminology as the most difficult here. I think of
"parts" as part of a mereological relationship, and don't know
how you define "parts".

> If so, I can understand model-T as model-2 with those specific
> differences, and that is a form of progress.
> 
> Do others pop up in your mind?
> 
> 
>>>And does the spectrum above make sense to you as a prop that can
>>>clarify how model-A and model-T differ?
>>
>>I think we can continue to discuss this and perhaps glean a better
>>understanding than I think at least I have right now.
> 
> I'm game.
> 
> 
>>I'm a bit
>>surprised we don't have more participation from the Topic Map
>>community in a discussion about facets in Topic Maps, but I'm
>>assuming everyone is busy, or maybe this discussion is happening
>>in the ISO list or has already been decided, or maybe people don't
>>consider conversations here binding or important so they're staying
>>with the ISO discussions. To me, it's still a hanging thread for
>>Topic Maps, and something I'd like to clear up with the help of
>>the whole community. I'm at the moment trying to implement something
>>reasonable (both in terms of human and machine reason), and I hate
>>to go it alone on this one.
>
> Me too.
>
>>There's plenty of confusion about facets
>>and properties, and a lot of overlapping terminology and
>>understanding/misunderstanding.
>
> No argument there.  :-)



Murray

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

    International lawyers and anti-war campaigners reacted with
    astonishment yesterday after the influential Pentagon hawk
    Richard Perle conceded that the invasion of Iraq had been illegal.
    http://www.guardian.co.uk/uk_news/story/0,3604,1089042,00.html

      "...if it's the case that international law doesn't permit
       unilateral pre-emptive action without the authority of the
       UN, then the defect is in international law."

    Thank God for the death of the UN, by Richard Perle
    http://www.guardian.co.uk/Iraq/Story/0,2763,918812,00.html