- From: Satya Sahoo <satya.sahoo@case.edu>
- Date: Tue, 14 Feb 2012 18:02:23 -0500
- To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Cc: public-prov-wg@w3.org
- Message-ID: <CAOMwk6xy+KWoxiwVfGnrsX=2COw=W-16zb4UNsf0fKey5=XL2w@mail.gmail.com>
Hi Paul and Luc, Thanks for your responses! There are issues with current description of prov:Literal which according to current definition in DM-TPWD Section 5.5.3 boils down to being a "quoted string". The note at the end of the section refers to OWL2. I will raise it as a new issues against TPWD, so I am fine with closing this issue. Thanks. Best, Satya On Mon, Feb 13, 2012 at 3:09 AM, Luc Moreau <L.Moreau@ecs.soton.ac.uk>wrote: > 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<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<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<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<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 <l.moreau@ecs.soton.ac.uk>> >>>>> United Kingdom http://www.ecs.soton.ac.uk/~**lavm<http://www.ecs.soton.ac.uk/~lavm> >>>>> <http://www.ecs.soton.ac.uk/%**7Elavm<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 <l.moreau@ecs.soton.ac.uk>> >>>> United Kingdomhttp://www.ecs.soton.**ac.uk/~lavm<http://www.ecs.soton.ac.uk/~lavm>< >>>> http://www.ecs.soton.ac.uk/%**7Elavm<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<http://www.ecs.soton.ac.uk/~lavm> > > >
Received on Tuesday, 14 February 2012 23:02:52 UTC