- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Thu, 06 Oct 2011 09:55:18 +0100
- To: public-prov-wg@w3.org
Thanks Paul for pointing this sentence out. I would like to see it rephrased along the lines: While the PROV Ontology is designed to be reused and specialized for representing domain-specific provenance information, its classes and properties are expected to be used directly while exchanging provenance information. Luc On 10/06/2011 09:45 AM, Paul Groth wrote: > Hi, > > I would like to emphasize Luc's comments: > > In particular, I'm also worried about this phrase: > > "The PROV Ontology is not designed to be used directly in a domain application and its Classes and Properties represent "higher-level" or abstract level concepts that can be specialized further for representing domain-specific provenance information." > > This seems to imply that one would not see any PROVONT concepts in documents on the web. If you look at what we want, is the ease of interoperability and that means the reuse of terms between applications on the web. (See the success of dublin core or schema.org). > > Maybe this can be rephrased? > > Thanks, > Paul > > > > On Thursday, October 6, 2011 at 10:39 AM, Provenance Working Group Issue Tracker wrote: > > >> 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 ... >> > > > -- 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, 6 October 2011 08:55:48 UTC