I Really Don’t Know

Whisky, Whisky, so good they named it twice

After lunch here at vocamp, Tom is putting up his initial thoughts about a Whisky ontology. His intention is to be able to describe aspects of Whisky such that you could run a shop from the data.

This is interesting as the things you want to know about a Whisky are pretty specific, it’s not a question of price.

Tom, like me, thinks about modelling in a nouns-first way. Chris Wallace is asking if this is the right way to model, as RDFS emphasises properties over classes. This is a very interesting insight and one I hadn’t considered. I had assumed that attaching classes to properties, through domains and ranges, was a different syntactic approach to attaching properties to classes. I hadn’t considered it as a different philosophical approach.

It is, though. In OO modelling, where we attach properties to classes the property is scoped by the class. That means that you have to have complex hierarchies if you want to the properties on one class to be semantically the same properties as on another class. In RDFS the property is the same by virtue of it being defined independent of classes it is used on.

Putting the philosophical debate aside, and getting back to the Whisky…

The classes Tom defined are:

• Whisky
  This class is used for the wide variety of Whiskys available. There is a possibility of splitting this into subclasses, or adding additional classes to denote single malts, pure pot stills or blended whiskys.
• Region
• Distillery
• Brand
• Finish
• Characteristic

There was also an assortment of properties proposed, most with specific domains and ranges, but I’ll not bother to note those here:

• region, owner, produces, motto, headDistiller, waterSource, age, finish, brand, label, abv, colourDesc, strengthLevel, year, grain

We then concluded that trying to define this as a group was hard, so tasked Ian and Tom to create an initial version based on the brainstorm and some genuine instance data and bring that back to the group.

Ian and Tom focussing on co-evolving the vocab alongside instance data was very interesting to watch. The resulting Whisky Ontology is up on vocab.org

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 by Sacred Destinations on Flickr