Skip to main content

The Observation API (hey, it's not the Observable pattern)

Posted by fabriziogiudici on April 29, 2009 at 4:25 PM PDT

As I said in  href="">February,
I'm going to post on my blog a series about the use of Semantic
Technologies and how they are being used in some of my projects.

Today let's start giving a small domain model and then design a related
abstract API. In the next post I'll show you how to
implement it on the top of a
RDF triple store.

Models style="font-weight: bold;">

API is designed to manage a set of "observations" (of whatever, by
anybody, etc... let's keep it generic in order to respect the "AAA
slogan": Anyone can say Anything about Any topic), so I'm
it "the Observation

Let's introduce the key abstractions:

  • An Observer
    represents entities capable to make observations. It may be a
    physical person, or a device, or anything else makes sense.
  • An Observation
    is made at a certain time and Location,
    by one or more Observers
    and is composed of one or more ObservationItems.
  • An ObservationItem
    pairs an Observable
    with a Cardinality.
  • An Observable
    has no special properties and can be anything.
  • A Cardinality
    may be a single integer number, a close or open range of integers (e.g.
    "between 10 and 20", or "more than 5"), or "undefined".
  • An ObservationSet
    is a set of Observations.
  • A Source
    is where a certain datum comes from (i.e. who or what provided it,
    inserting into the database).

Domain Model src="">

All of the above concepts are going to become classes, so I'm now
referring to them with the code typo convention. style="font-family: monospace;">Observer,
and Source
have a single property exposed through style="font-family: monospace;">getDisplayName(),
that is the identifier used for rendering the object in a UI. Applying
some common patterns, we add a few more classes for the solution model:

  • An style="font-weight: bold; font-family: monospace;">ObservationManager style="font-family: monospace;"> provides way
    to retrieve and create ObservationSets.
  • A style="font-weight: bold; font-family: monospace;">Finder
    is used to perform various queries.
  • An style="font-weight: bold; font-family: monospace;">Observation.Builder
    provides ways to create new Observations.

only architectural dependency introduced in the API is related to the
use of components


It would make sense to have a range for the Date. Let's say I didn't choose it for the first iterations, even though the application using this code is manipulating some thousands records and, up to the moment, there is not a strict need for it. But of course, at the moment I get JSR-310 in (see comments above) I could use the classes that represents an interval of time.

Hi Fabrizio, a natural (at least in my head) extension of the model could be using a range instead of a date; am I the first fool that thinks of it - maybe because I have completely misunderstood your intent - or have you explicitly decided to keep it this way? I'd like to hear the logic beyond this choice ps: great job... as always!

Of course. Thanks for the correction.

> > but while I'm confident with JodaTime and soon with JSR 311 > You meant JSR-310 : Date and Time API

Hi Stephen. My idea is not to use Date any longer (it has disappeared by all my paid projects, of course), but while I'm confident with JodaTime and soon with JSR 311, at the moment I don't know how to persist a date different than Date in the RDF store I've decided to use. I'm pretty sure it's possible, but I've left that for a future iteration. These APIs won't be frozen soon.

Since your API takes in a Date instance to define the date, your API may well yield different results depending on the time zone of the user running the code (perhaps persisted in one time zone and attempted to be read in another).