Larsblog

Previous | Next

tolog updates

Posted in Technology on 2006-02-21 20:49

The tolog query language has been around for a long time, but so far it only does querying, and not updates. As far as I know, no other query language for Topic Maps does updates, either. An update language is interesting for three reasons:

So what does a query language with update support look like? It basically needs to support three things:

In addition, it might be nice to support generating new information based on the existing topic map. This is useful for many purposes, but we can return to it further down.

Let's see if we can tackle these use cases one by one.

INSERT

This one is quite easy. All that's needed is a new type of tolog statement that starts with INSERT instead of SELECT, and which is followed by a description of the Topic Maps data to add in some Topic Maps syntax. The obvious candidate for this is LTM, which already exists and is well known, but which will need two minor modifications. Firstly, it will have to start supporting tolog prefix declarations instead of LTM directives. Secondly, it must support %foo% references to parameters, so that the insert statements can be reused.

This would mean that to add a new city in a geography topic map you could write:

INSERT
  [%new% : city = "%name%"]
  contained-in(%new% : containee, %country% : container)

For this to work you would need to pass in to the query a name for the new city and a country topic the city is contained in. The %new% parameter is a reserved parameter that always creates a new topic. This is necessary, because if you wrote something like mycity, every city created would have the same item identifier assigned, and thus every city would merge with every other city.

DELETE

This one is also easy. All that's needed for this is a way to state which objects to delete, and what the deletion rule for each object is. tolog already gives us a way to do the former, and the latter can easily be defined with some simpler containment rules on TMDM information item types.

Effectively, all that's needed is something that goes like this:

  DELETE list of variables
  FROM normal tolog query

This leaves only the deletion rules. These are simple, and state that each item type when deleted takes with it all items contained within it. The containment hierarchy runs as follows:

What this means is that if you delete an association, all the roles in that association are also deleted, but not the topics playing those roles. If you delete a topic, all its topic names, variants, occurrences, and the associations it plays roles in, will disappear.

So, to delete a country with all the cities in it, simply do the following:

delete
  $COUNTRY, $CITY
from
  instance-of($COUNTRY, country),
  { contained-in($COUNTRY : container, $CITY : containee) }

UPDATE

This one is the hardest, in part because it's much less obvious what the use cases are. A couple of years back I used to assume that all TMDM properties should be changeable in this way, but that seems clearly false now. Changing the type of an association, or the topics in the scope of a topic name is not the sort of thing an update language should do. In fact, an extremist might want to argue that there should be no updates at all, just insertions and deletions. Pragmatically, however, there seems to be a case to be made for operations like "change string value of name", "change topic at other end of association", etc.

But what is a good way to express these operations? One way to look at it is to consider each predicate in tolog to be the expression of a relationship (or fact, if you prefer). When querying one finds the variable matches that make the relationships hold, but the same could be applied to updates, in that one could assert that the topic map must be updated to make the relationship hold.

That would give us the following:

set
  value(@1232, "Oslo")

This would set the string value of object 1232 to "Oslo", so presumably 1232 is the topic name of some city topic. This should of course also work with parameters, and it should work with variables (provided there is a query part as well). This would give:

set
  value($TN, "Oslo")
where
  value($TN, "Christiania"),
  topic-name($CITY, $TN),
  instance-of($CITY, city)

There is a subtlety here, though. What if the city has more than one topic name with the same string value? Or if there are multiple cities with the same name? The only reasonable interpretation seems to be that all possible $TNs should have their string values set.

So which of the built-in tolog predicates should be supported? The following seem like they should obviously be supported when the argument in italics is bound:

In all of these cases, there can only be one possible value, so that value is then set. There are, however, some trickier cases, like these, where there are multiple values:

What to do in these cases is not clear. DELETE as described so far doesn't let us remove values for these, either, so simply supporting both delete and insert is not going to be sufficient.

There is also the issue of dynamic name, occurrence, and association predicates. Should they be allowed to do updates? They don't have zero-or-one cardinality, so the behaviour in these cases is likewise not obvious. There is a strong temptation to support these occurrences, since when they can be used (ie: when the name, occurrence, or association type has zero-or-one cardinality) it is much easier to do updates than when they cannot. One way to around this is to say that all names, occurrences, or associations of the given type are updated, regardless how many there might be.

Conclusion

Well. There isn't really time to write the conclusion, since my girlfriend just came home. I'll see if I can come back later and do it, but right now I just want this off my mind so I can talk to her. I'd be very interested to get comments on this to see what people's reactions are. Ontopia will probably implement this at some point, so feedback before we implement is better than after...







Similar posts

PSIs for Topic Maps constructs

One thing that's lacking in the current set of Topic Maps standards is defined identifiers for the Topic Maps constructs, like subject, topic, association, etc

Read | 2006-05-29 10:45

A TMCL tutorial

The TMCL standard now seems more or less stable, and so now it is finally possible to explain to outsiders what the language looks like and how it works

Read | 2008-10-03 17:33

A path language for Topic Maps

I sketched a little path-based query language for Topic Maps this summer, mostly to explore what such a language might look like

Read | 2009-09-23 11:01

Comments

No 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
> Home
> Technology
> Beer
> Personal

> The author .
> On Twitter

RSS

follow us in feedly

Subscribe by email:

My new book


Gårdsøl
det norske ølet

My other book

Guidebook to Lithuanian beer
Rough guide to
Lithuanian beer

Technology blogs

Robert Barta
TopicObserver.Com
Sveins blogg
Stephen Fry
ongoing
Messages in a bottle
Alex Brown
Planet Topic Maps

Last comments
RSS

Lars Marius Garshol on A sudoku solver in P...

Heinz-GŁnter on A sudoku solver in P...

alex bloom on Active learning, alm...

alex bloom on Experiments in genet...

kenneth mwelwa on 10 tips on presentin...

fadirra on 7 tips on writing cl...

Tim on 7 tips on writing cl...

elmarie on What is an informati...

p2r on 7 tips on writing cl...

Jeffrey White on The solera paradox