Re: PROV-O call summary

>>>> Hi Luc,
>>>> 
>>>> 
>>>> 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.


I think I overlooked this statement the first time.
How do we say that two events occur at the same time? DM only gives me "precedes" and "follows", and doesn't want me to talk about 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?

That sounds reasonable.
prov:GenerationEvent rdfs:subClassOf prov:Event .
prov:Event rdfs:subClassOf time:Instant. 

http://dvcs.w3.org/hg/prov/file/19e5ad36f03b/ontology/components/Event.ttl
aggregated by
http://dvcs.w3.org/hg/prov/file/098453cb6516/ontology/component-aggregations/prov-constraints.ttl


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

Not even when we want to tell others that the provenance records are dubious? The ordering constraints would be useful for an explanation.
While I agree Event-type vocabulary should be separated from the basic PROV-O, I'm not sure why we would want to isolate disparate systems that are looking at constraint violations.
Even when a system doesn't care about exchanging ordering constraints, it would still benefit from not reinventing the DM's modeling.

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

I agree. Do we have names for these partitions?


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

"broken" := provenance record violates a constraint.


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


I would use my component aggregation [1] to produce two separate OWL ontology files, but that has been unilaterally disregarded. So we'll make two OWL ontology files some other way.

[1] http://www.w3.org/2011/prov/wiki/PROV_OWL_ontology_components

-Tim



> Luc
>> -Tim