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