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