PROV-O LC feedback - ivan

From Provenance WG Wiki
Revision as of 16:38, 19 November 2012 by Tlebo (Talk | contribs)

Jump to: navigation, search

Here is the next one: prov-o.

There quite some comments here, but I do not believe any of those are real show stopper, ie, other than editorial. Although my question on prov:activity vs. prov:hadActivity is on the borderline:-(



- The status of the document says: "This is the third public release of the PROV-DM document." Oops, copy-paste error:-) (Not much to be done any more, though)


- At the moment, and are _not_ identical. Shouldn't they be?


Interestingly, if I read prov.rdf in Firefox through the tabulator extension, then it leads to an error, whereas prov.owl works perfectly. I am not sure why.


- jus being picky: the document should explicitly say that the 'prov' prefix stands for http://... and the 'owl' stands for http://... I know all the examples are o.k. by themselves, but these are used in the rest of the text and owl is used in table 3. The other prov documents have a text that could simply copied here verbatim...

CLOSED added the table,

- I am sure this was discussed before (and maybe I was also involved, sorry about that if that is the case…): what is the decision process to have both _and_ http://localhost:8001/TR/prov-o/prov-20120724.owl ? Ie, is it necessary to have the OWL ontology part of the /TR, too? I am just concerned about future error management: if there are bugs that we recognize later, then changing them in /TR is not possible where it is in /ns.

Paul, have talked to Guus about their experiences with SKOS on that matter? I think they went through quite some hooplas with the exact storage of their ontologies…
Now… we can say that the /TR version is a historical snapshot, together with the document itself. If that is the case then it becomes an editorial issue: the intro text in the abstract should somehow make it clear that SW tools should really really use the files in /ns (using conneg for turtle and owl), and the one in the /TR space is not to be used by tools. It is only a version of the final ontology.

CLOSED OBE since the document points to /ns for the ontology. We'll include a snapshot in ns, too. and VersionIRI.

- B.t.w., related to version, a wild idea: shouldn't there be a provenance information in the prov-owl file itself? Reflecting versions? Our own dog-food and all that…:-)

CLOSED we have wasRevisionOf to the last one, and versionIRI for the current version.

- I am a bit puzzled by the fact that the 'layering' terms used in prov-dm and in prov-o are different. Prov-dm talks about 'core' and not core, and then also uses the C1-C6 categories. Prov-o talks about starting point terms, etc, which is a different layering. 

I realize that core is not enough, because a number of qualified properties in prov-o are still 'core' when looking at them through prov-dm. But I still miss some sort of a connection between the two documents. Maybe a table or something that makes the relationships clear would be helpful. 

I find it puzzling, by the way, that the time related terms are in the 'starting' category in prov-o but are not mentioned at all in the 'core' structures of prov-dm (section 2.1)

I also realize that there is usually a back-reference to prov-dm from the prov-o terms. But if I come from the prov-dm side, it seems to be fairly difficult to find the corresponding owl term. Would it be possible to add something for those, too? A table or something…

CLOSED DM added a table of the mappings. and cites that table.

- again to make the connection among documents clearer: would it be possible to reuse figure 1 of prov-dm as figure 1 of prov-o (although the time issue is there, see my comment above)? It would make the connections clearer…


- would it be possible to bring the example in prov-o (Example-1) in line with the primer's example? It is almost the same, as far as I can see, but uses slightly different names…


- it may be worth, for the figures, to shortly describe the colour coding and shapes used for entities, activities, etc. Oh and… would it be possible to use the same shapes and colour as in the primer? After all, section 3 is, practically a primer by itself…


- I may expect some push back from the SW community on the fact that the inverse relations (prov:generated and prov:wasGeneratedBy) are so prominently among the list of properties (so that they appear expanded classes and properties' box, in the figure, etc.) Many consider defining such properties as a clear anti-pattern. 

I wonder whether it is not wiser to push those 'down', so to say, as a separate box maybe, and remove them from the initial examples. This would clearly simplify the figures, too, and would be much more in line with the current prov primer and and dm terms.

Actually, this is partially done already, see appendix B and the separation of the owl file (which is great). But the core text should be cleaned up accordingly in my view.


- There is a general issue of dependency on a TriG syntax in example 2, this has to be discussed separately. But, forgetting about that, I believe the right approach should be

:bundlePost a prov:Bundle .
:bundlePost { … }

rather than having the type definition within {}. The approach the RDF WG is moving towards is a 'quoting' semantics for named graphs, ie, an interpretation would consider, by default, the content of a {..} as a black box and would concentrate on the default graph only. In this respect, the typing information on the graph label should, probably, be part of the default graph…

(This is of course valid for the other examples, too)


- Figure 4: this is really a matter of taste, but the particular arrangements of the various pattern is a bit disturbing. Sometimes it is one pattern in a row, sometimes not… I know it would use up more space (though real estate on a web page is free…) but maybe a more regular arrangement would be better (in my view)


- It is instructive to look at figure 4 which makes use of 'prov:hadActivity' only once, everywhere else it uses 'prov:activity'. This suggests to me that maybe, but only maybe, 'prov:hadActivity' may  not be necessary. I looked at the definitions (though probably not spending enough time) and, I must admit, I fail to get a clear mental model of the difference between prov:hadActivity and prov:activity :-( So why do we have both?


- In Table 3 the OWL axioms are wrong. They should all be of
rdfs:domain [ owl:unionOf (prov:Activity prov:Agent prov:Entity prov:InstantaneousEvent) ]

(the ontology itself seems to be fine, it is only the text which is wrong)

CLOSED fixed

- Acknowledgement section: it is very flattering to asign rdflib to my name, but it is not justified. I have only a very very minor participation in rdflib (I have written/donated some modules) and I am certainly not part of the core designers and maintainers! 

CLOSED removed name for rdflib

There is also a discrepancy on whether all the members of the WG are listed (as it is the case for some other prov documents) or not, like in this one. I think we should be consistent all along!

OPEN will reuse from DM

- References: the dates of a number of prov documents are wrong (all are set to 2011:-)

OPEN will use biblio.js from Luc