A path language for Topic Maps

<< 2009-09-23 11:01 >>

Highrises, Oslo

I sketched a little path-based query language for Topic Maps this summer, mostly to explore what such a language might look like. My TMQL co-editor, Rani Pinchuk, asked me to write up a more detailed description of it, and that's what this blog posting is.

Please note that the intention is NOT that this is to replace the existing TMQL draft. This is just a little experiment to explore other forms a path language (as opposed to a full-blown TMQL) might take. It is not particularly complete. What happens to it is at the moment unknown.

Basics

Simply put, it works like this:

expression / axis::typefilter [ predicate ]

The initial expression can be any kind of expression that produces Topic Maps data, such as a variable reference, or a reference to a topic. The slash signals that here comes a path navigation step. The axis then says in what direction you are navigating from where you are, the typefilter refers to a type used to filter the objects returned, and the predicate is a boolean expression used for more detailed filtering. Of course, the predicate is optional, and can be left out. Every Topic Maps item type has a default axis, and so the axis:: part can also be left out. And, finally, * is used to indicate that any type is acceptable.

If we wanted my email address, we could find it as follows:

lmg / occurrences::email

The default axis for topics is the union of the name, occurrence, and role axes, so we could also do it like this:

lmg / email

If there is no initial expression this is interpreted to mean the topic map itself. The default axis for topic maps is the union of the topic and association axes. Thus, if we wanted to find the email address of every person in the topic map, we could do it like this:

/ person / email

If we instead wanted every person which has at least one email address we can use the predicate. Inside the predicate, period (.) is used to refer to what in XPath is called the context node. Thus, it would come out like this:

/ person [ . / email ]

Associations

To traverse the employed-by association from me the long-winded way, one would do as follows:

lmg / employee / parent::employed-by / employer / *

Since the default axis for topics includes the roles the first steps gives us all roles of type employee. The second step follows the parent axis to the association, which we filter by type for good measure. The third step follows the default axis from associations (which is the role axis) and filters it so that we only get employer roles. Of course, this gives us the role, so a final step is needed to find the player (which is the default axis from roles).

Obviously, this is not very pleasant, so a shorthand has been devised, which expands to the expression above:

lmg / employed-by(employee -> employer)

Some more examples

There is also a scope shorthand:

lmg / employee / parent::employed-by @past
  / employer / *

This would only produce the employed-by associations in the past scope. The shorthand is equivalent to:

lmg / employee / parent::employed-by [ . / scope::* == past ]
  / employer / *

Some more examples:

$person / subject-identifiers::*
  [ starts-with(., "http://psi.ontopedia.net") ]

$person / description @english

$person / tmdm:topic-name  # all names of the default type

Use case solutions

To give a bit more of the flavour of the language, let's try solving some of the TMQL use cases. These were never meant to be use cases for a path language, and so they're not the sort of query you're meant to do with a path language, but let's do it anyway.

5.2.2.1: "Retrieve all author names, i.e. the name of a topic which plays the role author in an is-author-of association."

# first doing it literally
/ * [ . / author / parent::is-author-of ] / name::*

# more natural
/ person [ . / is-author-of(author -> opus) ]

5.2.2.8: "Retrieve all topic identifiers of documents which have a download URL."

/ document [ . / download ] / item-identifier::*

5.2.2.14: "Retrieve all documents which have a title in german (i.e. a basename in the scope de)."

/ document [ . / name::* @de]

5.2.2.16: "Retrieve the identifiers of all topics which represent information resources on the ontopia.net server(s)."

/ * [ . / subject-locator::* [ contains(., "ontopia.net") ]]
  / item-identifier::*

5.2.2.23: "Retrieve a list of all occurrence items being of type email."

/ * / email

The axes

The axes on topic map items are:

• default -> topic + association
• topic
• association
• reifier

The axes on topic items are:

• default -> name + occurrence + role
• name
• occurrence
• role
• subject-identifier
• subject-locator
• item-identifier
• parent
• reified
• type

The axes on association items are:

• default -> role
• role
• reifier
• scope
• parent
• type

The axes on role items are:

• default -> player
• player
• reifier
• parent
• type

The axes on name items are:

• default -> variant
• variant
• reifier
• scope
• value
• parent
• type

The axes on occurrence items are:

• default -> nothing
• reifier
• scope
• value
• datatype
• parent
• type

The axes on variant items are:

• default -> nothing
• scope
• reifier
• value
• datatype
• parent

Formally, the axes are defined as functions. For example, the role axis is defined as: role(in : topic/association, out : role).

Similar posts

Comments

Add a comment

Name	required
Email	optional, not published
URL	optional, published
Comment
Spam	don't check this if you want to be posted
Not spam	do check this if you want to be posted