- From: Paul Groth <p.t.groth@vu.nl>
- Date: Sun, 12 Feb 2012 07:43:43 -1100
- To: Satya Sahoo <satya.sahoo@case.edu>
- CC: "public-prov-wg@w3.org" <public-prov-wg@w3.org>
Hi Satya, It's important to recognize that a prov:Literal is *not* an OWL2 literal. Mixing these two things leads to confusion. prov:Literal as the DM states can support IRIs. I think the DM purpose is letting different serializations decide how they want to encode types in their type system and thus is being agnostic. I guess, my conclusion is that it's perfectly fine to map prov:type to rdf:type in the PROV-O. Different serializations will adopt different ways of mapping to the dm. cheers, Paul 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. > > > 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? > > 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> >> > > -- Dr. Paul Groth (p.t.groth@vu.nl) http://www.few.vu.nl/~pgroth/ Assistant Professor Knowledge Representation & Reasoning Group Artificial Intelligence Section Department of Computer Science VU University Amsterdam
Received on Sunday, 12 February 2012 18:44:15 UTC