- From: Timothy Lebo <lebot@rpi.edu>
- Date: Mon, 16 Apr 2012 09:23:46 -0400
- To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- 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>
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 UTC