The project started this July, it is based at King’s College London and is funded by the Leverhulme Trust. I’m more involved with the digital aspects of the project, and as usual one of the first steps involved in the building of a digital resource (in particular, a database-backed digital resource) is the construction of a conceptual model that can represent the main types of things being dealt with.

In other words, it is fundamental to identify which are the things our database and web-application should ‘talk about’; later on, this model can be refined and extended so to become an abstract template of the data-manipulation tasks the software application must be capable of supporting (e.g. entering data into the system, searching and visualising them).

Here’s a nice example of the sculptures (a sarcophagus from Aphrodisias) that constitute our ‘source’ materials:

What are the key entities in the sculpture domain?

To this purpose, a few weeks ago we had a very productive brainstorming session aimed at fleshing out the main items of interest in the world of sculpture. This is a very first step towards the construction of a formal model for this domain; nonetheless, I think that we have already managed to pin down the key elements we’re going to be dealing with in the next two years.

Here’s a list of the main objects we identified:

• – People, such as craftsman’s etc..
• – Sculptures (of various kinds)
• – Materials
• – Tools
• – Generic processes that are part of a sculpting project, such as quarrying and transport.
• – More specific methods being used within a particular process, e.g. carving styles, or approaches to quarrying.
• – Traditions, conceptualisations of the ‘way of doing things’ that, in turn, can inspire the way methods and processes are carried out nowadays.

We encoded the results of our discussions in a mind map for better readability, and also in order to use a technology that would make it easier to share our findings later on. I added it below.. (in case the interactive image doesn’t work, you can find it here too).

Fleshing out the model a bit more

After a few weeks of work we did a reiteration of the conceptual map above. The good news was that it soon became evident to us that we got it quite right on the first round; that is, we didn’t really feel like adding or removing anything from the map.

On the other hand, we thought we should try to add some relations (= links, arcs) among the concepts (=bubbles) previously identified, so to characterize their semantics a bit more. I had a go at adding some relations first, and here’s the result:

I should specify that I have no knowledge whatsoever of the domain of sculpture, so the stuff I added to the map came out entirely from the (little) research I’ve been doing on the subject (on and off) during the last weeks.

At the same time, also Will and Ben (the art historians I’m collaborating with) worked independently at the task of fleshing out the mind map with more relations. Needeless to say, what they came up with is way more dense and intricate than what I could have ever imagined! This is probably not surprising, as one would expect to see a significant difference between a non-expert’s representation of a subject domain and another one which is instead created by experts. Still, it was interesting to see it happening with my own eyes!
Here it is:

The next step will be trying to reduce the (natural) complexity of the portion of the world we are representing to a more manageable size… then, formalize it, and start building our database based on that.. stay tuned for more!

The concept of data integration is even older than computers, it’s as old as the idea of data itself: all datasets that we use today, from a book to a collection of pictures, from a library catalog to census data, had to be collected by different people/entities and integrated.

Very true! I always thought that a “lessons learned from the (far away) past” class would be extremely useful to SW people. Maybe in a future SW academic course…

There is an implicit assumption among semantic web practitioners that once the data is in RDF and it’s using different ontologies, all it’s left to do is to find a way to map the various ontologies together and voila’, data integration at a global scale!

RDF might help simplify certain operations but the problem of integration is not about just the identifiers used by the data models but also by the act of modeling itself!

Very true. This is lessons learned #2. Philosophers spent two thousand years (in the western world only) trying to do this mapping, without success (or even the desire for it in some cases).

There are modeling mismatches that simply cannot be solved with ontological mappings alone.

This is a form of ‘undermodeling’, similar to the concept of aliasing and artifacts introduced by sampling: a data model is a way of sampling an information space. In audio processing, it’s obvious that mixing two samples with different sampling resolutions would result in total garbage no matter how one decides to align them in time.

We have a similar problem here: given a set of images of paintings where only one image per painting existed, the data model ‘undersamples’ that information space collapsing the two into one concept.

Following the same sampling rationale, we need to ‘resample‘ the data model and decouple the ‘works’ from the ‘images’, or convert the Museum location into coordinates. But this is far from trivial and clearly not something that can be done without intimate domain knowledge.

I really like this sampling – modeling metaphor! That’s really it! And here’s the conclusion:

This ‘resampling’ facility, in its most abstract shape, is nothing but a transformation stage: RDF comes in, RDF comes out, possibly different and more aligned with the rest we have to integrate.

Also while some of such transformation operations can be done unsupervised, in general human intervention (by an individual or either a voting group) will be required.

Also the ability to turn supervision into a ‘scripted’ set of transformation operations will be required. For XML one would use XSLT, but for RDF there is no such thing (there are rule languages on the horizon, but they hardly seem to fit these needs… even if XSLT wasn’t properly designed for XML transformations either).

I honestly don’t know how these tools will work , what shape they’ll have and how much automation they will be able to provide to human users, but one thing is for sure, while declarative equivalences help data integration with RDF, they are far from being enough and we can no longer afford to ignore this problem.

I don’t know either – but this seems a very clear problem definition. And often that’s the most important thing we need to get going in the right direction!