- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Thu, 05 Jan 2012 15:35:54 +0000
- To: Timothy Lebo <lebot@rpi.edu>
- CC: Provenance Working Group WG <public-prov-wg@w3.org>
Hi Tim, Further comments interleaved. On 01/05/2012 02:02 PM, Timothy Lebo wrote: > Comments within. > -Tim > > On Jan 5, 2012, at 1:55 AM, Luc Moreau wrote: > > >> Hi Tim, comments interleaved. >> >> Professor Luc Moreau >> Electronics and Computer Science >> University of Southampton >> Southampton SO17 1BJ >> United Kingdom >> >> On 5 Jan 2012, at 02:16, "Timothy Lebo"<lebot@rpi.edu> wrote: >> >> >>> Hi Luc, >>> >>> Thanks for looking through our notes. >>> >>> On Jan 4, 2012, at 6:14 PM, Luc Moreau wrote: >>> >>> >>>> Hi Tim, >>>> >>>> Can you clarify what you intent with "prov:follows and prov:precedes properties missing". >>>> >>> prov:follows a owl:ObjectProperty; rdfs:domain time:Instant; rdfs:range time:Instant . >>> similar for precedes. >>> (and I need to raise an issue to ask for "equals") >>> >> It's strange. In prov-dm, we make the case for events because two different events could occur at the same time. >> Follows and precedes are defined between events, but you modelled them as properties between instants. It seems conflicting. They should be properties between events (which may be known to exist but not the instant they map to). >> > time:Instants behave much like DM's events, in the sense that they are not explicitly mapped to a particular time and a degree of interpretation must be imposed to determine the partial ordering like in Events. This happens because the time:Instant is a (usually anonymous) resource that is described further to "nail down" what time the instant _actually_ occurred. The most common is time:inXSDDateTime ""^^xsd:dateTime, but a more verbose form is also provided that encodes each component in RDF triples. Other, more custom or more elaborate descriptions of time:Instants may also be used, in which case one would need to understand them and impose the interpretation that DM requires to make the ordering. > > > But events have got type: eg. generation, usage, etc. Shouldn't we introduce prov:event as subclass of time:Instants? >> >>> >>>> Follows and precedes are not part of the data model in the sense that they cannot be asserted by asserters. >>>> >>> Cannot or generally would not? >>> >> They are not provenance record. So they can't be asserted or inferred as provenance records. >> >> >> >> >>> Can they be inferred? >>> >> >> Not as prov record. Ordering Constraints are implied by provenance records. To me, it is an open question as to whether this is actually useful to express these constraints in rdf. >> > To me, it seems like a natural use of RDF, but I'll need to understand what constraints you're thinking of. > > As always, we need to understand what we are trying to achieve. We are concerned with exchanging provenance information. When exchanging provenance, I don't think it makes much sense to also exchange ordering constraints. >> >> >>> If so, then some RDF predicate is required to state the axiom and the result of applying the axiom. >>> Also, what can be inferred can be directly asserted. Why the distinction? >>> >> Why? Because they are not provenance records. They are general constraints that must be satisfied. I think there was also a desire to be "generous" and to allow for provenance records that break constraints. This would give us an indication of whether the records can be trusted or not. >> > If this position is common, then I guess the distinction _is_ needed. > RDF systems reason about RDF data by applying axioms that are encoded in RDF and result in further RDF assertions. > If we need to tailor PROV-O to developers that don't want to know how an RDF system reasons about the data, then we'll need a safely-hidden extension that semantic web developers will need. > > I think it's important that we distinguish what is the vocabulary to use for provenance interchange, from the potential reasoning that can be performed, which will be application and technology specific. > >>>> >>> Seems a bit odd that associations among Events would be in an extension, when they are fundamental to DM. >>> >> Do you actually model events? Is there a class event? >> > In iUser PROV-O, no. In system developer PROV-O, perhaps. Since they will need to find "broken" constraints and share this insight among systems. "Event" is a term used when describing "broken". > > > I don't think I understand this broken/event thing. > >> >> I am arguing for layering here: prov-dm records (essentially syntactic), ordering constraints(event interpretation), structural constraints. >> > > Sounds good. > > If it's good, then, how do you distinguish the various layers? Don't you have an ontology for each layer? Luc > -Tim > > > -- 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 Thursday, 5 January 2012 15:38:58 UTC