- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Thu, 08 Dec 2011 09:17:46 +0000
- To: public-prov-wg@w3.org
- Message-ID: <EMEW3|07a751151c08a444c7794769376a5312nB79Hn08L.Moreau|ecs.soton.ac.uk|4EE080BA>
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 Kingdom http://www.ecs.soton.ac.uk/~lavm
Received on Thursday, 8 December 2011 09:18:40 UTC