W3C home > Mailing lists > Public > public-prov-wg@w3.org > February 2012

Re: PROV-ISSUE-187: Section 5.2.2 (PROV-DM as on Nov 28) [prov-dm]

From: Paul Groth <p.t.groth@vu.nl>
Date: Sun, 12 Feb 2012 07:43:43 -1100
Message-ID: <4F38085F.3010704@vu.nl>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:06:56 GMT