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: Satya Sahoo <satya.sahoo@case.edu>
Date: Sat, 11 Feb 2012 18:57:47 -0500
Message-ID: <CAOMwk6ydXLtDH33JOY8twMZDpD_Z4aDTAcf8BauY58J3CLaHCg@mail.gmail.com>
To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Cc: public-prov-wg@w3.org
>
> 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?
>
> Please ignore the above statement, it is superfluous.

Thanks.

Best,
Satya


>
> 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
>>
>>
>
Received on Saturday, 11 February 2012 23:58:16 GMT

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