Data Dynamics in Semantic Systems (Part III)

(continued from Part II)

One thing Formula 3 (F3) was designed to help with is the quantitative transformation of time series. If you had to compute the mean values over an 1-hour interval of, say, the ticket sales then the following TSP operator takes care of it:

< [t-1 hour .. t].mean >
   every 10 minutes

With the ticket sales time series coming in, the start and the end times of that sequence will be considered. Starting with the series start time, and then every 10 minutes a time stamp will be generated. With that time stamp the processor will sample into the ticket sales series (symbolized by t) and will find all values in an 1-hour interval:

[t-1 hour .. t]

On this sequence of values the aggregation function mean is applied (several more such aggregators exist, and you may even define your own).

The overall outcome is another time series, with values 10 minutes apart, each value holding the gliding mean of the ticket sales (effectively a low-pass filter).

Property Management

Another, bigger, concern is to handle meta data properly.

As shown previously, you can add (and even compute) meta data from what the incoming series gives you. And that applies to each individual time slot in the series, but also to the series as a whole.

But you can (and should) test meta data on the incoming side of an operator as well:

@Tickets { f3:phenomenon => tou:ticket-sale }
   < @Tickets[t-1 hour .. t].mean >
   every 10 minutes

As above, we compute the gliding mean. But this time we are explicitly specifying what our expectations are on the incoming side:

  • only one sequence is consumed, one which is named locally @Tickets, and
  • that one sequence must be about ticket sales. If not, it will make kaboooom!.

[Sidenote: Java-heads may now niggle that the @ symbol makes the language look like Perl. And that the curly brackets may make it look like C. And that the dot makes it look like Python. And the QNames like Notation3. And the <> like XML. And the every like ...

Well, Java-people are dismissive like that. They seem a bit ... syntactically sensitive. On the same hand, I also dismiss people based on the way they look. Nothing superficially wrong with that. End of Sidenote}8-]

Making the incoming explicit also opens the door to name more than one series:

@Tickets { f3:phenomenon => tou:ticket-sale }
@Temp    { f3:phenomenon => tou:temperature }
  < @Tickets[n]
           { +temperature => @Temp(t) }
  > every tick of @Tickets

Now the TSP is always confronted with two series:

  • the first is about ticket sales,
  • the second about temperature.

The every clause makes the processor visit every time slot of @Tickets. And for each of these time stamps, the value @Tickets[n] is taken.

That value will be enriched with meta data, in particular the temperature. It will be sampled off the @Temp time series, using the current time stamp t (that of the ticket!) as reference time.

The plus + in front of the temperature property indicates that all other properties existing in the Ticket slot are retained. That way you do not have to repeat them over and over again.

Semantic Transformations

That property management may also make use of an underlying RDF graph. But in order to query into that graph one needs a lean query language.

For RDF the query language is SPARQL. But the problem(s) I have with SPARQL make it nearly impossible to embed within F3. Instead I am working on adapting myTMQL onto RDF(S) and using that.

How that works I will show some other time.

Posted In