- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Mon, 13 Feb 2012 07:58:01 +0000
- To: Satya Sahoo <satya.sahoo@case.edu>
- CC: public-prov-wg@w3.org
- Message-ID: <EMEW3|7f85aa670eff94ff3d32432d4a228a66o1C7w508L.Moreau|ecs.soton.ac.uk|4F38C289>
Hi Satya, On 02/11/2012 02:46 AM, Satya Sahoo wrote: > Hi Luc, > My responses are interleaved: > > 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. > > The definition of prov:type "PROV-DM liberally defines a type as a > category of things having common characteristics." from DM TPWD is > definition of a "class" in knowledge representation/ontology. In other > words, prov:type is same as rdf:type, we are just using slightly > different words to describe it? Also, please consider that using > prov:type implicitly brings in the notion of distinguishing between > "class/category" and "instance/value" (TBox, ABox from DL) - is that > what you and Paolo have in mind for DM? > > > Also, "only states that the value associated with a prov:type > attribute /must/ be conformant with Literal." is using same words as > OWL2 Literal, but misinterpreting the construct. OWL2 Literal maps to > specific datatypes (described in Section 4 of OWL2 syntax > (http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Datatype_Maps), > which are primarily XSD datatypes. I am not sure how prov:type > conforming to Literal can be used to link a specific value to a > category for that value (a Class in other words) - a Class/category is > not a XSD datatype value? I believe this constraint should be removed. > > Literal is to be understood as PROV-DM literal, this has been debated at length in ISSUE-142. We shouldn't reopen the issue, unless there is something new. It's reasonable to map prov:type to rdf:type. But remember the rdf mapping is not the only one. Finally, we shouldn't consider bringing notion of Tbox, etc. I don't see the need. > 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. > > Why would it not be valid - given an open world assumption, one can > always add new information to a record? > Let's step back. We have attributes with given values for entities, over their duration interval. Having a similar notion of attributes for activities make the model simple. If there is a need to talk about something that changes, then it should be modelled as an entity, and you can express its changes by means of derivation, etc. Given the above, what is left in this issue? Regards, Luc > Thanks. > > Best, > Satya > > > > > > > > > > > > >> >> 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 <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 Kingdomhttp://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 Monday, 13 February 2012 07:58:36 UTC