- From: Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>
- Date: Mon, 5 Mar 2012 17:33:12 +0100
- To: Provenance Working Group WG <public-prov-wg@w3.org>, Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Message-ID: <CAExK0Dcr9-9Q=Z+pepB3cM__Y6YRwJVKqvKxBMiHGnZD2dfXWQ@mail.gmail.com>
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, 5 March 2012 16:33:40 UTC