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

[Murray Altheim]

Thomas B. Passin wrote:
 > [Murray Altheim
[...]
 > I do not actually have any problem with using a facet association (for
 > example) to associate facets with a topic.  It could make a whole lot of
 > sense.  But where will you put their values?  A topic has only one place to
 > hold values - in an occurrence (a name doesn't count here, so far as I am
 > concerned).  Take eye color as a facet of a person.  If I have some topic of
 > type "color" playing the role of "eye color" in a facet association, where
 > does the value "blue" go?  Or did you want to create a topic of type
 > "blueColor", and by definition it represents the color blue?

Some people may want a want a set of enumerated values for things such as
eye color, whereas others will want values. The former is an already-solved
problem, the latter requires my nifty Datatypes in XTM thingamabob to type
a resource, which could be an inline value (e.g., the PCDATA content of a
<resourceData> element) or a reference to a value (e.g., a URI that returns
a value, using perhaps XPointer or some other type of query). Or you can
come up with some other way too, like MIME-types-as-PSIs, etc.

To answer your question, the value "blue" goes in the occurrence of the
faceting topic. *This* is not semantically incorrect, because the topic
happens to actually have as its type "facet" (not "Mother"). Then you can
use the entire complexity of <baseName> if you want complex property names,
or just use something simple. And you can both type and scope the occurrence
value (e.g., Datatypes for XTM) By having a faceting topic, you're not mucking
with the semantics of topics and occurrences, you're using them as designed.
When we still were working within TopicMaps.Org and decided not to include
facet support directly in XTM, we did so with the idea that XTM had a way
of expressing facets without resorting to new syntax. And I must say that
had we designed a facet element or attribute or link or whatever, it wouldn't
have the potential power of simply using the existing Topic machinery with
a couple of PSIs to establish facet-related meanings.

 > There are at least three ways to represent properties, and each of them has
 > a place.  Sowa in his book published in 2000 illustrated thus.  If you need
 > to make statements about the property , it should presumably be a topic of
 > its own.  If you only care about the property type and value, I would like
 > to be able to do it in some simpler way.

I have that book on my desk. Which pages are you referring to? The one
index entry wasn't very helpful, and the appendices don't seem to have
anything.

 > Also, not everyone likes to model properties as facets.

Ah, but I don't expect everyone to use my vunderbar idea. Just me. Anyone
else is gravy. That's the nice thing about PSIs. Because we didn't hardwire
the semantics into XTM, if you don't like my way, you do it your own way.
Human communication requires this kind of variety, as I'm sure you'd agree.

[...]
 >>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),
 >
 > Although the occurrence types can participate in hierarchies just as well,
 > for that matter.

Yes, of course. But because I'm principally interested in the ontology
within the topic map and not so much what I'm mapping, I don't do a lot
with occurrence types. Now, if you're talking about occurrence types within
faceting topics, well, that's another matter. But I think I've already
covered that.

 > Plus, I have to do a whole lot more work just to come up with a few lousy
 > properties to display - I have to be able to walk up the whole type
 > hierarchy just to figure out if some role is really supposed to be a
 > property.  Or do you have a clever shortcut (I bet you do!)?

I don't know if I'm understanding this complaint exactly, because on
the one hand it's an incredibly simple traversal (how deep do you think
you might get, 20 levels?) *or* you already know it's a property (in
the context it's being used) because the beginning of your traversal
is an association whose other member is playing the role of "facet".

Put it this way, in my application there's planned a small scrolling
list of topics that play the role of facet in a "hasFacet" association
with the current topic. I wrote a traversal method to do superclass-
subclass, and all I've got to do is alter the choice of PSIs to do
the facet traversal, with perhaps a few minor variations (such as the
fact that a taxonomy has the same association type throughout, but
once one has traversed the facet-to-topic association, what do you
do next? I.e., what information are you trying to obtain?).

 >>>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...)
 >
 > Ah, but I want LESS, LESS, LESS!  At least, less complication.  I want some
 > very common things to have the possiblility of simplicity.  I grant you that
 > when you want to make a lot of statements about properties, they gotta be
 > topics playing roles in associations.

I'm hoping that simple things will stay simple. If you're not interested
in complication, you make an association to something whose type is
"hasFacet" (or whatever one wants to call it), and make sure the topic
playing the role of facet has that PSI in its member's roleSpec. All
the rest, such as hierarchies, complex names, etc. are optional. If
there are people who don't have a problem with using occurrences to
model facets, they might steal my PSIs and use them for that. I wouldn't
recommend that as best practices, but I'm not on the Semantic Police Force.

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