[topicmapmail] Fragmented XTM for web metadata, and some ontology?

[Murray Altheim]

Thomas B. Passin wrote:
> [Murray Altheim]
>>I don't think it's appropriate semantically to include properties
>>of a given topic as occurrences of that topic -- it's just not
>>sensible, doesn't "read" right to me. You yourself stated the sentence:
>>
>>     "here is the resources"
>>
>>which is essentially saying "here are the untyped values". Since we
>>want to both name and type our values, and because occurrences don't
>>have names, each facet is a topic.
>
> I really do not agree with Murray here at all.  First of all, occurrences
> __can__  have types - they have their instanceOf topics.  If you argue that
> we have no standard way to assign a datatype to any topic except in prose, I
> agree, but I think we should be able to state the datatype of an occurrence
> value.  I have posted on this before.  Two ways to do so are to specify its
> MIME type or to us an XML Schema data type, as you can now do in the latest
> drafts of RDF.

The seeming lack of a method to do something does not argue for doing it
in a way that collides with the existing model. An occurrence of a topic is
an occurrence of a topic. Now, both 13250 and XTM describe occurrences as
something "relevant" to a topic, which frankly to me is an extremely weak
statement in terms of commitment. Any kind of relationship whatsoever could
be considered "relevant" by that standard. It is what the standard says,
however, so strictly speaking you're correct.

But I'd not model an ontology that way. And I will be proposing a method
to keep properties of things distinct from topic occurrences, as I prefer
to think of them, which if one thinks of a topic map as a map of some
territory, properties (depending on their use) are part of the ontology/map,
and occurrences are part of the territory being mapped.

> Anyway, using a topic instead of an occurrence does not solve the problem of
> data type, because we cannot say that a particular topic is of some data
> type either - at least, we can only do it in prose.

Ah, but yes we can. But you're trying to get me to reveal my secrets. :-)
Basically, if we have a PSI for "facet" we can type topics that are facets,
using their names and occurrences as named properties, and associating them
with their topics via a proper association. Now, there's a few people that
will tell you that occurrences are just a specialized type of association,
and while that's not wrong in my book, once one begins decomposing a topic
map, you end up with a-nodes and t-nodes, etc., which is like looking at an
automobile engine as a series of metal and plastic surfaces and connectors
rather than the higher-level components. An occurrence is an occurrence, and
if it were just a special sort of association, we'd have gotten rid of
occurrences. (anyway, I don't want to decompose topic maps, I want to use
them as they are)

> So we can have named and typed occurrences (modulo the data type issue), and
> so an occurrence can perfectly well represent a property name/value pair.  I
> use them like that all the time.

I'm assuming you're getting your topic name from the <instanceOf> of the
<occurrence>. One of the problems with that is that if I want to express
that an occurrence is a facet of a topic, I need to use that <instanceOf>
to express that and I'm left with no place to put the name. Absent a
facet-type, an occurrence can't be identified as a facet, unless you want
to type the typing topic as a facet, but in a typical ontology you'd perhaps
have to type *everything* as a facet since any particular topic might play
many different roles, e.g., in Cyc, "eye color" is a subject in its own
right, but might play the role of a property of a human being. And while
it's possible to create association types for every single possible property
("personHasEyeColor", "personHasHeight", "personHasBirthdate", etc.), it's
much nicer to be able to simply assign properties.

> If you are a purist, you probably think that an occurrence should be
> considered a syntactic shorthand for a particular style of association.  If
> you think that way, go ahead and make up topics and associations.

Ooh, I should read ahead. I'm apparently not a "purist" then.

> Not only that, for most people, there is a real distinction between
> properties and associations.  Properties have Pierce's "firstness", while
> relationships have "secondness" (if I understand that right - feel free to
> reread Sowa about this).  Therefore they should be modeled differently.  The
> only other modeling construct we have besides the association is the
> occurrence.

I agree, but that's precisely why I'm advocating a specific semantic
(which would be defined in a PSI) creating *specifically* a facet association,
which in 13250 is a specific thing, akin to a property, i.e., that's the
language used in 13250. I think (and feel free to disagree, I don't consider
myself necessarily correct about this, I'm having a discussion to help iron
out my own understanding here too) that arguing Peircean logic at the level
of Topic Map Associations and Occurrences is conflating different levels of
representation, to wit: I could create a PSI for Peirce's "firstness", another
for "secondness", and a third for "thirdness", and we'd be fine. Topic Maps
are just the toolkit upon which we mold our ideas. They themselves need not
intrude at all. In XTM we delivered a "core" set of "semantics" for superclass-
subclass and class-instance associations, and we (speaking for myself anyway)
deliberately didn't define those so tightly as might be desired by some, such
as the definitions of "class" etc. I'm happy about that, because for probably
95% of web applications and 99% of web users, the distinctions are lost. And
for those who desire or need finer or more "accurate" definitions, they can
define their own PSIs.

> Finally, as a practical matter, if I model my properties as associations, it
> is much harder for me to know which topics are supposed to be properties and
> which ones are not.  It would be really hard to make a list of the
> properties of some topic but not bring in other associated topics.  On what
> basis would you be able to distinguish the two?  You do not want to have to
> know beforehand which topic types are supposed to be properties.  Well, you
> could give them (their names) a "properties" scope, that would work, I
> suppose.  Sounds like a hack, though.

Actually, the little devious scheme in my head (which I will someday
publish when I'm not spending so much time in email :-) certainly enables
traversal of the graph as according to properties, and in fact that's
precisely why I'm approaching it the way I am. I simply look out from
a given topic and see what "hasFacet" associations it is a member, and
from the member role I can determine which is the topic and which is
the property. And because properties can themselves fit into their own
hierarchies and themselves have properties (as Kal has indicated), I'm
not constricting myself to what can be handled within occurrences. And
the distinction between what is a property and what isn't is all a question
of modeling, not one to constrict at this level anyway.

> So I plump for using occurrences for properties.  Maybe there are some
> exceptions, and if you want to be able to say anything else about those
> property instances, obviously you have to make topics for them.

But I do. As I mentioned, things that are properties of other things
are themselves things having properties, playing roles in associations
with other things, mereological relations with other things, having
their own facets (as in XSD, min, max, default, etc.). I'd feel pretty
impoverished if all I could use was occurrences, which is what I've
done up until now too. I WANT MORE! MORE! MORE! (as I figuratively
pound my glass top desk into submission...)

Murray

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

        "There's a lot of intelligence out there that you don't
         know if it's true or not."  -- Anonymous US official
         http://news.bbc.co.uk/1/hi/world/middle_east/3014850.stm