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: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Date: Wed, 15 Feb 2012 12:36:27 +0000
Message-ID: <EMEW3|2f175b2c6928ae118c3d6d84cd5ca830o1ECaW08L.Moreau|ecs.soton.ac.uk|4F3BA6CB.2020609@ecs.soton.ac.uk>
To: Satya Sahoo <satya.sahoo@case.edu>
CC: public-prov-wg@w3.org
This issue is now closed, Satya,
Thanks,
Luc

On 02/14/2012 11:02 PM, Satya Sahoo wrote:
> 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 
> <mailto: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
>
>                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>
>                     <tel:%2B44%2023%208059%204487>
>                            University of Southampton fax: +44 23 8059
>                     2865 <tel:%2B44%2023%208059%202865>
>                     <tel:%2B44%2023%208059%202865>
>                            Southampton SO17 1BJ email:
>                     l.moreau@ecs.soton.ac.uk
>                     <mailto:l.moreau@ecs.soton.ac.uk>
>                     <mailto: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>
>                     <http://www.ecs.soton.ac.uk/%7Elavm>
>
>
>
>
>                    --
>                    Professor Luc Moreau
>                    Electronics and Computer Science   tel:+44 23 8059
>                 4487 <tel:%2B44%2023%208059%204487>
>                 <tel:%2B44%2023%208059%204487>
>                    University of Southampton          fax:+44 23 8059
>                 2865 <tel:%2B44%2023%208059%202865>
>                 <tel:%2B44%2023%208059%202865>
>                    Southampton SO17 1BJ email:l.moreau@ecs.soton.ac.uk
>                 <mailto:email%3Al.moreau@ecs.soton.ac.uk>
>                 <mailto: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>
>                 <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 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
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 Wednesday, 15 February 2012 12:37:06 GMT

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