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: Tue, 14 Feb 2012 18:02:23 -0500
Message-ID: <CAOMwk6xy+KWoxiwVfGnrsX=2COw=W-16zb4UNsf0fKey5=XL2w@mail.gmail.com>
To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Cc: public-prov-wg@w3.org
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 GMT

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