Re: PROV-O call summary

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.


> 
>> 
>>> 
>>> 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.

> 
> 
>> 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.


>>> 
>> 
>> 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 am arguing for layering here: prov-dm records (essentially syntactic), ordering constraints(event interpretation), structural constraints.


Sounds good.

-Tim

Received on Thursday, 5 January 2012 14:02:51 UTC