W3C home > Mailing lists > Public > public-prov-wg@w3.org > October 2011

Re: PROV-ISSUE-104 (time-class): How to relate start/end time to PE, use, generation, etc [Formal Model]

From: Jim McCusker <mccusj@rpi.edu>
Date: Fri, 14 Oct 2011 09:52:56 -0400
Message-ID: <CAAtgn=SnAufMPv7nEzEAE9_=iOYmM-yTO-61tQy3_PAX5ZLZdA@mail.gmail.com>
To: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
Cc: Paul Groth <p.t.groth@vu.nl>, Provenance Working Group WG <public-prov-wg@w3.org>
Have we considered looking at and possibly adopting time.owl?

I know it's specifically an onology, but they've already looked at how to
represent time formally, so if we can align with them, we probably should.

http://www.w3.org/TR/owl-time/

On Fri, Oct 14, 2011 at 5:14 AM, Stian Soiland-Reyes <
soiland-reyes@cs.manchester.ac.uk> wrote:

> The DM constraint generation-unicy (or so) says that if in a single account
> asserts:
>
> wasGeneratedBy(e, pe1, q1)
> wasGeneratedBy(e, p2, q2)
>
> then:
> p1==p2 and q1==q2
>
> I assume it follows that also the generation times would equal, but that
> should probably be added to the constraint. Therefore a single functional
> prov:wasGeneratedAt should be OK.
>
> Now it is open for discussion if this constrain interferes with
> subprocesses where an entity can be seen as "generated two places at once",
> or if that should be solved by two (potentially roled) entities or two
> accounts.
>
> You can do the same EntityInRole construct for prov:wasGeneratedBy.
> Syntactically each of these are new entities, can all have prov:assumedBy
> :e1 but  different prov:assumedRoles, prov:wasGeneratedAt (and in theory
> prov:wasGeneratedBy).
>
> By the constraint they should then be interpreted as the same generation
> process and qualifiers (including role). You can think of it as an inference
> rule when an entity in role states its generation:
>
> x prov:assumedBy e1
>   prov:wasGeneratedBy :p1
>   prov:wasGeneratesAt :t1
> -->
> x prov:wasComplementOf e1
> e1 prov:wasGeneratesBy :p1
>   prov:wasGeneratesAt :t1
>
> ie they overlap, but have common start time. Again stating entity start/end
> time (characterisation unrerval) would make this easier.
>
> At the same time I feel that this pushes EntityInRole to its limits. That's
> good, because we need to see if it is up to the job.
>
> Tim, Satya, any comments?
> On Oct 14, 2011 4:50 AM, "Paul Groth" <p.t.groth@vu.nl> wrote:
>
>> This is a good start:
>>
>> But how is for example wasGeneratedAt associated with a particular process
>> execution generated pair. Or do we assume that two such edges shouldn't
>> occur?
>>
>> I guess this done through the blank node in the used example is that
>> correct?
>>
>> Thanks for this
>> Paul
>>
>> On Oct 14, 2011, at 1:30, Stian Soiland-Reyes <
>> soiland-reyes@cs.manchester.ac.uk> wrote:
>>
>> >> On Thu, Oct 13, 2011 at 17:49, Paul Groth <p.t.groth@vu.nl> wrote:
>> >>
>> >>> I was wondering if examples of time could be put in the PROV-O Crime
>> >>> Example. Like they are in PROV-DM.
>> >>>
>> >>> It would be cool to see how we can put times against:
>> >>>
>> >>> used,
>> >>> wasGeneratedBy
>> >>> Provenance Execution.
>> >
>> > I threw together one suggestion on how to do it using a few new
>> properties:
>> >
>> > http://dvcs.w3.org/hg/prov/file/tip/ontology/components/Time.ttl
>> >
>> > declares:
>> >
>> >  prov:startedAt
>> >  prov:endedAt
>> >  prov:assumedRoleAt
>> >  prov:wasGeneratedAt
>> >
>> >
>> > For example, from
>> >
>> http://dvcs.w3.org/hg/prov/file/285b39f7ea5f/ontology/components/Time/example-1.ttl
>> >
>> > # start/end
>> > :pe1 a prov:ProcessExecution ;
>> >    prov:startedAt :tA ;
>> >    prov:endedAt :tB .
>> > :tA a prov:Time .
>> > :tB a prov:Time .
>> >
>> >
>> > # generation time
>> > :e1 a prov:Entity ;
>> >    prov:wasGeneratedBy :pe1 ;
>> >    prov:wasGeneratedAt :tC .
>> > :tC a prov:Time .
>> >
>> >
>> > # used time
>> > :pe2 a prov:ProcessExecution ;
>> >    prov:used [
>> >        a prov:EntityInRole;
>> >        prov:assumedBy :e1;
>> >        prov:assumedRoleAt :tD
>> >    ] .
>> > :tD a prov:Time .
>> >
>> >
>> > # controlled time
>> > :a1 a prov:Agent .
>> > :tE a prov:Time .
>> > :pe2 prov:wasControlledBy [
>> >        a prov:EntityInRole, prov:Agent;
>> >        prov:assumedBy :a1;
>> >        prov:assumedRoleAt :tE;
>> >    ] .
>> >
>> >
>> > You can from this of course also specify generation using EntityInRole
>> > and assumedRoleAt - but as an entity can only be generated once
>> > (right?) we might as well just say prov:wasGeneratedAt.
>> >
>> >
>> >
>> > Note to self:
>> > Allow intervals for role/use/control? - (prov:assumedRoleStart and
>> > prov:assumedRoleEnd)?
>> > Sounds like special cases of characterisation intervals..
>> > prov:startedAt and prov:endedAt could also be used with prov:Entity ?
>> >
>> >
>> >
>> > I looked at the crime file example, and did:
>> >
>> >
>> http://dvcs.w3.org/hg/prov/file/285b39f7ea5f/ontology/components/Time/example-2-crimefile.ttl
>> >
>> > .. but it does not really say much about time at all:
>> >
>> >
>> > #processExecution(pe1,add-crime-in-london,t+1,,[])
>> > :pe1 a prov:ProcessExecution, cf:FileAppending ;
>> >    prov:startedAt :t1 .
>> >
>> > #processExecution(pe2,email,t+2,,[])
>> > :pe2 a prov:ProcessExecution, cf:Emailing ;
>> >    prov:startedAt :t2 .
>> >
>> >
>> >
>> > So here's a practical example of how to do an extension, for instance
>> > using OWL Time:
>> >
>> >
>> http://dvcs.w3.org/hg/prov/file/285b39f7ea5f/ontology/components/Time/example-3-extension.ttl
>> >
>> > Including the simplest case without using the subclasses:
>> >
>> > # Lazy straight forward version - no declared subclasses
>> > :pe0 a :ProcessExecution ;
>> >    prov:startedAt [
>> >        # a prov:Time, time:Instant ;
>> >        time:inXSDDateTime "2011-12-24T14:24:05Z"
>> >    ] ;
>> >    prov:endedAt [
>> >        time:inXSDDateTime "2011-12-25T01:41:54Z"
>> >    ] .
>> >
>> >
>> >
>> >
>> > --
>> > Stian Soiland-Reyes, myGrid team
>> > School of Computer Science
>> > The University of Manchester
>>
>


-- 
Jim McCusker
Programmer Analyst
Krauthammer Lab, Pathology Informatics
Yale School of Medicine
james.mccusker@yale.edu | (203) 785-6330
http://krauthammerlab.med.yale.edu

PhD Student
Tetherless World Constellation
Rensselaer Polytechnic Institute
mccusj@cs.rpi.edu
http://tw.rpi.edu
Received on Friday, 14 October 2011 13:53:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:06:44 GMT