I _Really_ Don't Know

A low-frequency blog by Rob Styles

Vocamp 2008 Oxford

We're sitting in Wolfson College, Oxford in a smart little meeting room overlooking a grassy quad. Nice location.

We've just done introductions and I'd be a liar if I said I wasn't intimidated by the number of PhDs in the room. There are people with substantial experience in neuro-science, computer science, insect genetics, philosophy and, of course, lots of semweb experience.

Having split into groups, my colleague Ian Davis is just demoing OpenVocab to a few of us. This is an alpha project based on the notion of collaborative schema development - in the wiki style. So far the tool lets you create terms or classes within the OpenVocab namespace and add descriptions, labels, domains and ranges to them.

His intention is to solve what he sees is a problem in publishing linked data - where you are mostly using existing ontologies but need to add a class or a property there is an effort required to publish that single class or property that isn't worth it. OpenVocab is intended for publishing these simple adhoc extensions.

In the wiki vein, it keeps a version history of changes and anyone (within some as yet undecided constraints) can edit the descriptions of terms.

We talked about how this might affect the way people engage with the communities surrounding individual ontologies and the relationship between this and the formalisation of meanings of tags, perhaps. I would prefer to get any extensions I need into the original ontology - and have done with both sioc and bibliontology, but failing that, OpenVocab offers a quick easy way to get those little things out there.

Discussion moves on to the problem we all seem to have - how to formally describe a composite ontology. By Composite Ontology I mean an ontology that expects that you will use parts of other ontologies - in the way that bibliontology uses dcterms.

While human readable examples are crucial for this kind of composition, a formal description may also be key if we are to achieve generic creation and editing tools and/or for visualisation or validation.

I was hoping someone would say "ah, yes, you just have to..." but that wasn't forthcoming. Besides making sure they're in human documentation, suggestions currently are

  1. Don't mention them
  2. Copy the definitions from their own ontologies into yours, but don't relate them in any way
  3. Create your own and use subclass, subproperty or sameAs to relate them
All of these have their own problems, but broadly 2 seems to be the best bet right now - combined with human examples and documentation, of course.

There was a comment that Peter F. Patel-Schneider at Manchester may be doing some work on modularity of ontologies and fine-grained imports. Maybe that's what's needed.

Great lunch, sponsored by Talis :-)

Photo, [eos 015](http://www.flickr.com/photos/sacred_destinations/661835676/) by [Sacred Destinations](http://www.flickr.com/photos/sacred_destinations/) on [Flickr](http://flickr.com)


dev8D | Lightning talk: Agile Development | I Really Don’t Know

[...] is Graham Klyne who I’ve met a few times at various meets like Vocamp 2008 in Oxford. He and his team are doing clever things with pictures of flies and semweb [...]

Rob Styles

Option 2 above, I meant copying the whole definition, including the original URI - absolutely not minting your own URI. In terms of why that's not enough... One of the directions of self-describing data is that we can start to build interfaces that can work with many different types of data. Say I want to build an editing tool today to work with Bibliontology (aka bibo). Bibo doesn't include a property of 'title' even though it's about describing bibliographic works. It defers to DC Terms for title (and some other things too). This is documented in a human-readable form, but there is no machine-readable explanation of this that would allow me to know that a user creating a new bibo:Document should be prompted to add a dcterms:title to it. This seems odd, as we encourage each other to produce ontologies that rely on, or defer to, other ontologies.


I am so sad I couldn't make it... Re. modularity: why is just mentioning the URIs of the external terms you want to use in your ontology not enough? We did that with MO, and it seems to work well. It even allows (with some efforts) to not break the DLness of an ontology when you want to use a non-DL ontology (e.g. FOAF). Or maybe it is part of solution 2 - do you mean copying the whole definition (including the term URI), or minting your own URI?