PlanetData
Deliverable Review Form
Part I - Comments List
deliverable
name
Call2: Linked Map VGI Provenance
Schema
month deliverable due
Other participants
Irene Celino
2014/03/10
Sent back to authors
(date)
2014/03/17
SCIENTIFIC
comment
1
2
3
1
D16.1
42
lead participant
Responsible person
reviewer
Sent for review
(date)
deliverable number
In the intro you cite some (relevant) papers. It should be worth citing a
full special issue of TGRS that was exactly devoted to the topic of
provenance in geospatial data:
http://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=6646288
In the above cited issue there are several papers that are relevant for
D16.1 topic. Maybe you could have a look at them to understand if
what you did is in line with other authors’ work
In section 3.2 and also later on in the doc you use a notation that was
never introduced; if I’m not wrong it is PROV-N notation. Either you
make it explicit, telling the reader where an explanation of that
notation is available or you use another notation that should be
familiar to the reader. (Personally, since I think most of the interested
readers would be from the Semantic Web community I’d have used
RDF/Turtle.)
(C)ompulsory
(H)ighly
advisable
(O)ptional 1
H
O
C
Do the authors have to address the comment in order to make the deliverable final (Compulsory)? Is it
advisable but not compulsory to address the comment to make the deliverable final (Advisable)? Is it a minor
comment that is optional to be addressed by the authors for the final version (Optional)?
PlanetData
SCIENTIFIC
comment
4
5
6
7
8
9
Was the li:primaryTopic definition really mandatory??? Having a
quick review at PROV-O I’m not entirely sure why you didn’t use
prov:hadPrimarySource (being Bundle an Entity, it should perfectly
work). Moreover there are a number of other terms in other
vocabularies or ontologies that could have served the same purpose
(off the top of my head: dc:subject cf. http://purl.org/dc/elements/1.1/,
foaf:topic cf. http://xmlns.com/foaf/spec/, …). What I believe
mandatory for you is to explain why existing terms from PROV-O or
from other ontologies were not up to the task.
Same comment for li:scope. Couldn’t it be replaced by some definition
of “containment” between entities? Some part-of relationship would
probably do; another chance I see is to reuse something from the Data
Cube vocabulary (e.g. qb:Slice, see http://www.w3.org/TR/vocabdata-cube/) since you are mainly referring to datasets. Again, please
explain why pre-existing definition were not suitable in your case
I don’t understand the need for section 3.5 and annex B. why did you
need an XML definition of your extension? Do you have tools that
require XML so you were forced to define it? either explain the need
for it or remove the section/annex
In section 3.6 you provide an example of use of the schema (again
using the same un-named notation of section 3.2). What you don’t tell
here, however, is why you need to represent such provenance
information in the first place and how you will use it. in case you
explain this in some other deliverable, it would be worth putting a
reference to it. The generic explanation in the introduction
“provenance is important to assure data quality” does not strongly
support the need for it in your specific case.
The example provided in section 3.6 refers to the provision of a full
OSM dataset (dump) from Geofabrik & Co. However, it culd be
possible also to describe the provenance of a single OSM user
contribution. Do you want to track also that kind of provenance?
Why/why not? If yes, is your model still suitable?
Sorry for the self-citation, but some time ago, in the context of
PlanetData, I developed an extension of PROV-O to take into account
Human Computation efforts (http://swa.cefriel.it/ontologies/hc),
motivated exactly by a VGI use case (cf.
http://dx.doi.org/10.1109/TGRS.2013.2252015). I would be very
interested in understanding if my model would have fitted your
purpose and, if not, why. I mark this comment as optional, because it
can sound a bit selfish, but take into account that the project reviewers
may remember about my work and ask you for the interplay.
Deliverable D<xxx>
(C)ompulsory
(H)ighly
advisable
(O)ptional 1
C
C
H
H
O
O
Page 2 o
Deliverable D<xxx>
INSEMTIVES
ADMINISTRATIVE (e.g layout problems (empty pages, track changes/comments
visible), broken links, missing sections (Introduction, Conclusion, etc.), incomplete TOC,
spelling/grammar mistakes
comment
(C)ompulsory
(H)ighly
advisable
(O)ptional 2
1
In several places you say that ISO 19115 is “quasi-linear”: what do
C
you mean by that? Explain or rephrase
2
While informative, the entire section 2 is a summary of an existing
H
standard. Was it really worth including such a long explanation in this
document? Why are you telling the reader about it instead of pointing
him/her to the relevant reference? (For example, I found it a bit
annoying the several figures for all the updates of the standard:
probably the latest one was more than enough.) If you still think it is
worth 7 pages, you should add an introductory paragraph motivating
why you thought it important to have such a section in order to
understand what you did and what follows in the document.
3
All the links to “linkedmap” domain return a 404 error! Fix them to
C
return the expected documents!!!
4
Annex A presents the same content in 2 different formats. It is very
H
unlikely that a reader would need both. I’d recommend to delete the
RDF/XML version (since it is not very human-friendly) and leave only
the Turtle version.
Part II – Summary
overall marking
Comments
VG (very good) / G (good) / S (generally satisfactory
/ P (poor)
I think the deliverable could have been much shorter
overall. On the other hand, I think the authors could
have motivated much better (and longer) the need for
provenance modelling in their project
After addressing the Quality Assessor’s comments, report back to him/her re-using this review form.
2
Do the authors have to address the comment in order to make the deliverable final (Compulsory)? Is it
advisable but not compulsory to address the comment to make the deliverable final (Advisable)? Is it a minor
comment that is optional to be addressed by the authors for the final version (Optional)?
© INSEMTIVES consortium 2009 - 2012
Page 3 of (3)