- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Mon, 13 Feb 2012 08:09:55 +0000
- To: public-prov-wg@w3.org
Hi Paul and Satya, I agree with Paul, 'Literal' was the focus of ISSUE-142, which has now been closed. Luc On 02/12/2012 06:43 PM, Paul Groth wrote: > 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> >>> >> >> > -- 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 08:10:21 UTC