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

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
>> 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
>>
>>
>>
>
> --
> 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
>
>