An occasional blog.

November 2011

How can we package, manage, mix and merge graph datasets that come from different contexts, without getting our data into a terrible mess?

During the last W3C RDF Working Group meeting, we were discussing approaches to packaging up ‘graphs’ of data into useful chunks that can be organized and combined. A related question, one always lurking in the background, was also discussed: how do we deal with data that goes out of date? Sometimes it is better to talk about events rather than changeable characteristics of something. So you might know my date of birth, and that is useful forever; with a bit of math and knowledge of today’s date, you can figure out my current age, whenever needed. So ‘date of birth’ on this measure has an attractive characteristic that isn’t shared by ‘age in years’.

At any point in time, I have at most one ‘age in years’ property; however, you can take two descriptions of me that were at some time true, and merge them to form a messy, self-contradictory description. With this in mind, how far should we be advocating that people model using time-invariant idioms, versus working on better packaging for our data so it is clearer when it was supposed to be true, or which parts might be more volatile?

The following scenario was posted to the RDF group as a way of exploring these tradeoffs. I repeat it here almost unaltered. I often say that RDF describes a simplified – and sometimes over-simplified – cartoon universe. So why not describe a real cartoon universe? Pat Hayes posted an interesting proposal that explores an approach to these problems; since he cited this scenario, I wrote it up as a blog post.

Describing Dilbert: theory and practice

Consider an RDF vocabulary for describing office assignments in the cartoon universe inhabited by Dilbert. Beyond the name, the examples here aren’t tightly linked to the Dilbert cartoon. First I describe the universe, then some ways in which we might summarise what’s going on using RDF graph descriptions. I would love to get a sense for any ‘best practice’ claims here. Personally I see no single best way to deal with this, only different and annoying tradeoffs.

So — this is a fictional highly simplified company in which workers each are assigned to occupy exactly one cubicle, and in which every cubicle has at most one assigned worker. Cubicles may also sometimes be empty.

Every 3 months, the Pointy-haired boss has a strategic re-organization, and re-assigns workers to cubicles.

He does this in a memo dictated to Dogbert, who will take the boss’s vague and forgetful instructions and compare them to an Excel spreadsheet. This, cleaned up, eventually becomes an emailed Word .doc sent to the all-staff@ mailing list.

The word document is basically a table of room moves, it is headed with a date and in bold type “EFFECTIVE IMMEDIATELY”, usually mailed out mid-evening and read by staff the next morning.

In practice, employees move their stuff to the new cubicles over the course of a few days; longer if they’re on holiday or off sick. Phone numbers are fixed later, hopefully. As are name badges etc.

But generally the move takes place the day after the word file is circulated, and at any one point, a given cubicle can be fairly said to have at most one official occupant worker.

So let’s try to model this in RDF/RDFS/OWL.

First, we can talk about the employees. Let’s make a class, ‘Employee’.

In the company systems, each employee has an ID, which is ‘e-‘ plus an integer. Once assigned, these are never re-assigned, even if the employee leaves or dies.

We also need to talk about the office space units, the cubes or ‘Cubicles’. Let’s forget for now that the furniture is movable, and treat each Cubicle as if it lasts forever. Maybe they are even somehow symbolic cubicle names, and the furniture that embodies them can be moved around to diferent office locations. But we don’t try modelling that for now.

In the company systems, each cubicle has an ID, which is ‘c-‘ plus an integer. Once assigned, these are never re-assigned, even if the cubicle becomes in any sense de-activated.

Let’s represent these as IRIs. Three employees, three cubicles.

http://example.com/e-1

http://example.com/e-2

http://example.com/e-3

http://example.com/c-1000

http://example.com/c-1001

http://example.com/c-1002

We can describe the names of employees. Cubicicles also have informal names. Let’s say that neither change, ever.

e-1 name ‘Alice’

e-2 name ‘Bob’

e-3 name ‘Charlie’

c-1000 ‘The Einstein Suite’.

c-1001 ‘The doghouse’.

c-1002 ‘Helpdesk’.

Describing these in RDF is pretty straightforward.

Let’s now describe room assignments.

At the beginning of 2011 Alice (e-1) is in c-1000; Bob (e-2) is in c-1001; Charlie (e-3) is in c-1002. How can we represent this in RDF?

We define an RDF/RDFS/OWL relationship type aka property, called eg:hasCubicle

Now, come March 10th, everyone at the company receives an all-staff email from Dogbert, with cubicle reassignments. Amongst other changes, Alice and Bob are swapping cubicles, and Charlie stays in c-1002.

Within a week or so (let’s say by March 20th to be sure) The cubicle moves are all made real, in terms of where people are supposed to be based, where they are, and where their stuff and phone line routings are.

The fictional world by March 20th 2011 is now truthily described by the following claims:

Questions / view from Named Graphs.

1. Was it a mistake, bad modelling style etc, to describe things with ‘hasCubicle’? Should we have instead described a date-stamped ‘CubicleAssignmentEvent’ that mentions for example the roles of Dogbert, Alice, and some Cubicle? Is there a ‘better’ way to describe things? Is this an acceptable way to describe things?

2. How should we express then the notion that each employee has at most one cubicle and vice versa? Is this
appropriate material to try to capture in OWL?

3. How should a SPARQL store or TriG++ document capture the different graphs describing the evolving state of the company’s office-space allocations?

4. Can we offer any practical but machine-readable metadata that helps indicate to consuming applications
the potential problems that might come from merging different graphs that use this modelling style?
For example, can we write any useful definition for a class of property “TimeVolatileProperty” that could help people understand risk of merging different RDF graphs using ‘hasCubicle’?

5. Can the ‘snapshot of the world-as-it-now-is’ view and the ‘transaction / event log view’ be equal citizens, stored in the same RDF store, and can metadata / manifest / table of contents info for that store be used to make the information usefully exploitable and reasonably truthy?