W3C home > Mailing lists > Public > public-prov-wg@w3.org > April 2012

Re: PROV-ISSUE-117 (general-comments-on-formal-model-document): General Comments On Ontology Document [Formal Model]

From: Timothy Lebo <lebot@rpi.edu>
Date: Mon, 16 Apr 2012 09:23:46 -0400
Cc: Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>, Provenance Working Group WG <public-prov-wg@w3.org>
Message-Id: <BA9B89B9-09F2-41DE-96E6-1DBD81159ED4@rpi.edu>
To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Luc,

The current PROV-O HTML document has de-emphasized the extensibility discussions.

Is it satisfactory to close this issue? If not, what concern remains?

Thanks,
Tim

On Mar 5, 2012, at 11:43 AM, Luc Moreau wrote:

> Hi Daniel,
> 
> I am aware the html document is being designed.
> The spirit of this issue still holds, though.  I think we shouldn't close
> it just now, but only after we have seen the next provo html draft.
> 
> Luc
> 
> On 05/03/2012 16:33, Daniel Garijo wrote:
>> 
>> Hi Luc,
>> the ontology document is being reestructured (Khalid just sent an email with the proposed
>> structure of the html), and the possible extensions have been separated in a best practices document.
>> 
>> Can we close this issue?
>> Thanks,
>> Daniel
>> 
>> 2011/10/6 Provenance Working Group Issue Tracker <sysbot+tracker@w3.org>
>> 
>> PROV-ISSUE-117 (general-comments-on-formal-model-document): General Comments On Ontology Document [Formal Model]
>> 
>> http://www.w3.org/2011/prov/track/issues/117
>> 
>> Raised by: Luc Moreau
>> On product: Formal Model
>> 
>> 
>> Comments about the document
>> ---------------------------
>> 
>> Assuming the ontology issues described above are solved, then there is the question
>> of how the specification document should present the ontology.
>> 
>> My *key* concern is that the document's motivation is *not aligned*
>> with the charter.
>> 
>> The ontology document says:
>> 
>> - This ontology specification provides the foundation for
>>  implementation of provenance applications
>> - The PROV ontology classes and properties are defined such that they
>>  can be specialized for modeling application-specific provenance
>>  information
>> - The PROV ontology is specialized to create domain-specific
>>  provenance ontologies that model the provenance information specific
>>  to different applications.
>> - The PROV ontology consists of a set of classes, properties, and
>>  restrictions that can be used to represent provenance information.
>> - The PROV Ontology is conceived as a reference ontology that can be
>>  extended by various domain-specific applications to model the
>>  required set of provenance terms
>> 
>> But the charter says:
>> - The idea that a single way of representing and collecting provenance
>>  could be adopted internally by all systems does not seem to be
>>  realistic today.
>> - A pragmatic approach is to consider a core provenance language with
>>  an extension mechanisms that allow any provenance model to be
>>  translated into such a lingua franca and exchanged between systems.
>> - Heterogeneous systems can then export their provenance into such a
>>  core language, and applications that need to make sense of
>>  provenance in heterogeneous systems can then import it and reason
>>  over it.
>> 
>> So, it seems that there is a mismatch in motivation.  The
>> standardization effort is about *exchanging provenance information*
>> and not on how to represent it internally into systems.
>> 
>> Section "4. Specializing Provenance Ontology for Domain-specific
>> Provenance Applications" provides examples of how to specializa the
>> ontology for specific applications. Are we saying this is normative?
>> Is it the only way do it? My view is that this is purely illustrative
>> and non normative.  The document should make this clear.
>> 
>> I would even suggest that it needs to be presented differently. The
>> focus should not be on how to specialize the ontology. Instead, it
>> should demonstrate how applications, with specialized ontologies, can
>> still interoperate.
>> 
>> I thought that coming up with a series of normative MUST/SHOULD
>> requirements would have been useful to establish interoperability
>> criteria.  What should we see in the RDF serialization to ensure
>> serializability?
>> e.g. prov:Agent/Entity/ProcessExecution must be explicitly visible ...
>> 
>> 
>> 
>> 
>> 
Received on Monday, 16 April 2012 13:34:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:07:03 GMT