W3C home > Mailing lists > Public > public-prov-wg@w3.org > January 2012

Re: PROV-ISSUE-187: Section 5.2.2 (PROV-DM as on Nov 28) [prov-dm]

From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Date: Tue, 17 Jan 2012 23:14:52 +0000
Message-ID: <EMEW3|7bb913c21646b7468388e1c75778732eo0GNGE08L.Moreau|ecs.soton.ac.uk|4F1600EC.8010803@ecs.soton.ac.uk>
To: public-prov-wg@w3.org

Hi Satya,
In addition to my previous response, please also see:
http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html#dfn-type
for definition of prov:type.

Luc

On 08/12/11 09:17, Luc Moreau wrote:
> Hi Satya,
> Comments interleaved.
>
> On 12/08/2011 01:38 AM, Satya Sahoo wrote:
>> Hi Luc,
>> Apologies for my delayed reply to your earlier mail. I have responded 
>> to your comments in ISSUE 101.
>>
>> One response is interleaved:
>>
>>     To address this specific example, I am not sure what you are
>>     trying to express, since the attribute status
>>     is application specific. But for example, you could write
>>
>>     activity(a1, [status="composing text", status="uploading
>>     attachment", status="sending", status="sent"])
>>
>>     meaning that the activity a1 had a status with one of the
>>     possible values "composing ...", "uploading", ..." sent".
>>
>>
>> Ok, so the values of an attribute can be assigned from a list of 
>> possible values? Then the current requirement that attribute values 
>> have to hold "... for its whole duration..." is not a requirement.
>
> This is actually a good example to develop. Imagine that the activity 
> also had an extra status value: status="spellchecking",
> but we don't include it in the activity record.
>
> In such a case, a record such as
> activity(a1, [status="composing text", status="uploading attachment", 
> status="sending", status="sent"])
>
> would not be valid, because during the duration of the activity, there 
> is a status "spellchecking" that is not represented.
>
> This requirement of having attributes with given values  is also 
> present in entities. The driver for this requirement is
> that to be able to express provenance, we need something that is 
> fixed, from some perspective.
>
>
> I propose to add this example to the document, and explain this. Is 
> this an appropriate course of action?
>
>>
>>     The duration is given by the interval between start and event.
>>
>>     To some extent, an entity interval or an activity interval are
>>     opaque, we just know that some attributes
>>     hold for the duration.
>>
>>     If you want to describe that something changes in an activity.
>>     Say it was on hostA, and then on hostB,
>>     then, you need to express this as two separate activities. 
>>
>>
>> I believe this is an application-dependent requirement whether an 
>> activity running on hostA is different or same when it is running on 
>> hostB. For example, a Tomcat daemon running on port8080 or port80 
>> will be considered the same activity by a user browsing an online 
>> book store.
>>
>>     Likewise, if you want to say running, paused, running,
>>     you also have to have separate activities.
>>
>>
>> In case of an OS, the thread will have the same process id across its 
>> different states.
> We are digressing, is your point related to interval addressed?
>>
>>     What definition would you like to see for type? Intentionally,
>>     it's open ended, so that we don't constraint
>>     application to using specific typing approaches.
>>     Further information is also available in the type attribute in
>>     http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html#record-attribute
>>
>>
>> I raised the issue since it matches the rdf:type attribute already 
>> defined and well known in the Web community it will be a source of 
>> confusion prov:type vs. rdf:type. The example given in Section 5.5.1 
>> does not clarify how to interpret it. If we want it to be open-ended, 
>> then do we need to make it a reserved DM attribute?
>
> Fine, but we are not defining the mapping to rdf here, we are defining 
> prov-dm.
> It seems perfectly reasonable to say that the prov-dm attribute type 
> is expressed by rdf:type in an rdf:serialization.
>
> This said, not all typing systems involve classes (as understood by 
> rdf) and not all typing systems use URI to represent
> types. That's why prov-dm just states that the value of a type 
> attribute is a prov-dm literal.
>
> Luc
>>
>> Thanks.
>>
>> Best,
>> Satya
>>
>>
>>
>>     Luc
>>
>>     On 12/07/2011 01:53 AM, Provenance Working Group Issue Tracker wrote:
>>
>>         PROV-ISSUE-187: Section 5.2.2 (PROV-DM as on Nov 28) [prov-dm]
>>
>>         http://www.w3.org/2011/prov/track/issues/187
>>
>>         Raised by: Satya Sahoo
>>         On product: prov-dm
>>
>>         Hi,
>>         The following are my comments on Section 5.2.2 of the PROV-DM
>>         as on Nov 28th 2011.
>>
>>         Section 5.2.2:
>>         1. "attributes: a set of attribute-value pairs [ attr1=val1,
>>         ...], representing other attributes of this activity that
>>         hold for its whole duration."
>>         "an activity record's attribute remains constant for the
>>         duration of the activity it represents."
>>
>>         Comment: I have raised this issue before - why does the
>>         attribute values of an activity have to hold for its whole
>>         duration? Why is this constraint necessary or enforceable?
>>         If emailing is an activity a0 with attribute "status", then
>>         how do we represent [status="composing text"],
>>         [status="uploading attachment"], [status="sending"], and
>>         [status="sent"]?
>>         In addition, what does "duration" of activity mean - the time
>>         when it is "active" or between its "start event" and "end
>>         event"? What about "paused event"?
>>
>>         2. "The attribute type is a reserved attribute of PROV-DM,
>>         allowing for subtyping to be expressed."
>>
>>         Comment: Exact definition of "type" is absent?
>>
>>
>>         Thanks.
>>
>>         Best,
>>         Satya
>>
>>
>>
>>
>>
>>     -- 
>>     Professor Luc Moreau
>>     Electronics and Computer Science   tel: +44 23 8059 4487
>>     <tel:%2B44%2023%208059%204487>
>>     University of Southampton          fax: +44 23 8059 2865
>>     <tel:%2B44%2023%208059%202865>
>>     Southampton SO17 1BJ               email:
>>     l.moreau@ecs.soton.ac.uk <mailto:l.moreau@ecs.soton.ac.uk>
>>     United Kingdom http://www.ecs.soton.ac.uk/~lavm
>>     <http://www.ecs.soton.ac.uk/%7Elavm>
>>
>>
>>
>
> -- 
> Professor Luc Moreau
> Electronics and Computer Science   tel:   +44 23 8059 4487
> University of Southampton          fax:   +44 23 8059 2865
> Southampton SO17 1BJ               email:l.moreau@ecs.soton.ac.uk
> United Kingdomhttp://www.ecs.soton.ac.uk/~lavm
>    
Received on Tuesday, 17 January 2012 23:16:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:11 UTC