Re: PROV-O call summary

(Something went wrong in your email formatting, so it can be tricky to
see below who said what)

On Thu, Jan 5, 2012 at 19:14, Timothy Lebo <> wrote:

>> But events have got type: eg. generation, usage, etc.
>> Shouldn't we introduce prov:event as subclass of time:Instants?

> That sounds reasonable.
> prov:GenerationEvent rdfs:subClassOf prov:Event .
> prov:Event rdfs:subClassOf time:Instant.

In an early attempt, I used OWL time directly, making an Activity be
an time:Interval as well, with :started meaning both time:hasBeginning
and prov:startedAt.

(I've changed ProcessExecution to Activity below)

:TimedActivity a owl:Class ;
    rdfs:subClassOf prov:Activity ;
    rdfs:subClassOf time:Interval .

:Time a owl:Class ;
    rdfs:subClassOf prov:Time;
    rdfs:subClassOf time:Instant .

:started a owl:ObjectProperty ;
    rdfs:subPropertyOf time:hasBeginning ;
    rdfs:subPropertyOf prov:startedAt ;
    rdfs:domain :TimedActivity ;
    rdfs:range :Time .

:ended a owl:ObjectProperty ;
    rdfs:subPropertyOf time:hasEnd ;
    rdfs:subPropertyOf prov:endedAt ;
    rdfs:domain :TimedActivity ;
    rdfs:range :Time .

This would allow us to relate activities in a partial ordering
directly using time relations, even if we never say the actual time.

:pe2 a :TimedActivity ;
    # starts immediately after :pe1
    time:intervalMetBy :pe1;
    # lasts until :pe3 finishes
    time:intervalFinishes :pe3 .

:pe3 a :TimedActivity ;
    # Started some time after :pe1 finished
    time:intervalAfter :pe1 .

(Unfortunately the OWL Time spec does not specify what all those
intervalFinishes etc. mean - but the original papers by Allen and
Furgerson has a nice graphics explaining this, which we could
replicate in our documentaiton)

You could do a similar thing - although not as smooth in my opinion -
by relating the (already time:Instant) activity start and stops.

I would argue that all these should/could be time:Intervals (e.g. have
a start, end and optionally a duration):

QualifiedInvolvement (e.g. Usage, Generation, etc)

and therefore could be related with as little or as much time
information as is available.  I believe such explicit    time details
is important for provenance exchange, in particular when the account
has an incomplete view of the whole process, but might have observed
when something happened.  (And merging accounts with unsynchronized
clocks will be easier, as one can ignore the timestamps and only use
the partial ordering).

OWL Time does not (as far as I understand) require instants to be
consistent to be valid statements - so an account might still be free
to say something illogical like "a follows b follows a", it will not
break in an OWL-way, just on a semantic level.

(Side note: In duration of Generation, it is the *start* time of the
generation that signifies that the generated entity was ready - the
old "generation time" - this is then consistent in that the qualified
entity must overlap with the beginning of the qualified involvement -
if there is a non-zero duration beyond this this signifies that the
activity still did something to complete generation of the entity
(such as logging its creation, saving it to disk or transferring it
over the network)).

Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Friday, 6 January 2012 12:18:38 UTC