Subtyping statements

<< 2007-07-13 18:50 >>

Zen meditation garden, Ryoan-ji, Kyoto, Japan

Subtyping topic types has been supported in Topic Maps ever since the beginning, but support for subtyping statement types is much spottier, and, it turns out, trickier. In essence, subtyping of statements follows the same three rules as subtyping of topics. (You may find my introduction to subtyping useful if you don't know which three rules I mean.) There are, however, some quirks.

I don't show it in my examples below (it was hard to find good examples that didn't require lots of explanation), but one of the main uses of subtyping of statements is for interoperability between ontologies. Subtyping statements allows you to use your own specific vocabulary while at the same time allowing people to query/use your data in terms of a less specific but more widely shared vocabulary. Using your own metadata vocabulary derived from Dublin Core might be one example.

Subtyping of names

This is pretty straightforward. Let's say that we have, for whatever reason, decided to use dc:title as the type of the names of documents we classify in our topic map. However, we also want these names to be the default names for our resources, and there is a different name type for that, provided as part of the TMDM. So, what to do? Well, easy! We make dc:title a subtype of the default name type.

In LTM (using a simple extension to support typed names) that would run like this:

tmdm:supertype-subtype(tmdm:topic-name : tmdm:supertype,
                       dc:title : tmdm:subtype)

[b115 : foo:blog-entry = "Subtyping statements" : dc:title]

So what would this mean? Simply stated, it would mean that this topic map would be logically equivalent to the following topic map:

tmdm:supertype-subtype(tmdm:topic-name : tmdm:supertype,
                       dc:title : tmdm:subtype)

[b115 : foo:blog-entry = "Subtyping statements"
                         "Subtyping statements" : dc:title]

In other words: the subtyping would mean that whenever you add a name of type dc:title that implies the existence of a name of the default type. So this plays nicely with software that expects the default names to be there (and supports subtyping of names). The same of course applies to occurrences.

Complications

Problems

It shouldn't require much reflection to see that the situation as described up to this point is pretty much identical to that for topic types. There are, however, some complications. The first is scope. Topics are not scoped, but names and occurrences are. I won't go into it here, but I have some unpublished work that shows that the scope must be inherited from the original statement to any statements inferred by the subtyping. So that's fine.

But what about variant names? Should they be implied too? I think so, but to be honest I am not entirely sure.

Then there is the question of associations. Here things get somewhat more complex. Let's say we have a situation that occurs quite often in taxonomies: the relationship between two of our taxonomy terms is part/whole, and we want to say that, but at the same time we want to use the standard broader/narrower relation to build our taxonomy. We want to do this because elsewhere in our taxonomy we sometimes have just broader/narrower, and in other places we may have type/instance or supertype/subtype. So: we want to be specific, but also retain the simple, generic hierachical relationship.

Again, we can do this with subtyping. Like this:

part-whole(europe : whole, norway : part)

tmdm:supertype-subtype(tech:broader-narrower : tmdm:supertype,
                       part-whole : tmdm:subtype)
tmdm:supertype-subtype(tech:broader : tmdm:supertype,
                       whole : tmdm:subtype)
tmdm:supertype-subtype(tech:narrower : tmdm:supertype,
                       narrower : tmdm:subtype)

As you can see, it's not enough to subtype the association type; we have to also subtype the roles. And this is where it gets tricky. If we follow the current TMQL semantics, the same query for broader-narrower(broader, narrower) would match all three of the associations below:

part-whole(europe : whole, norway : part)
tech:broader-narrower(europe : whole, norway : part)
tech:broader-narrower(europe : tech:broader, norway : tech:narrower)

So how are we to know which of the last two statements to infer from the first? Well, we could choose to infer both (and also the two combinations where one role is replaced, but not the other). This doesn't feel terribly clean, but it does give the desired behaviour. Alternatively, we could say that we need access to a TMCL schema that tells us what the correct roles to use in broader-narrower are.

I'm not sure yet how to resolve this, but we will need to resolve it quite soon.

Similar posts

Comments

No comments.

Add a comment