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