My first suggestion would be to try and change the rec documents, and
use prov:hasprovenance.
If we can't, I like Paul's option.
Luc
On 26/02/2013 09:34, Paul Groth wrote:
Hi Graham,
given that we already staged the documents and things cannot be
changed it seems like (a) is the best option as we can add the note in
the paq. Maybe we can reserve both prov:hasProvenance and
prov:hasprovenance ? Is that doable?
thanks
Paul
On Tue, Feb 26, 2013 at 9:30 AM, Graham Klyne <g...@ninebynine.org
<mailto:g...@ninebynine.org>> wrote:
Hi,
[I'm keeping this off-list for now, because if Ivan says there's
nothing we can
do at this juncture, I see little point in opening the issue for wider
discussion. I am cc'ing www-archive so there's a record of our
discussion.]
This is a bit embarrassing, given an email I wrote just a couple
of days ago.
I'm working through comments on PROV-AQ, and Stian has raised the
following:
[[
32) According to http://tools.ietf.org/html/rfc5988#section-4.2
When extension relation types are compared, they MUST be compared as
strings (after converting to URIs if serialised in a different
format, such as a Curie [W3C.CR-curie-20090116]) in a case-
insensitive fashion, character-by-character. Because of this,
all-
lowercase URIs SHOULD be used for extension relations.
Should we not have relation URIs that are all lowercase to avoid
problems? ie.
Link: <http://acme.example.org/provenance/super-widget>;
rel="http://www.w3.org/ns/prov#hasprovenance";
]]
I had completely missed this in RFC5988, and had forgotten about
Stian's comment
when I replied a couple of days ago.
If we hadn't just been through the incorporation of provenance
links into the
published documents, I'd suggest changing "hasProvenance" to
"has_provenance" to
avoid the problems noted.
So, what now? I see a few options:
(a) keep the same name, and simply note that, when used as a link
relation,
prov:hasProvenance is compared case-insensitively.
(b) if it's not too late, change the property name
(c) define a second property that is all lowercase, and declared
equivalent to
the first.
As far as I can tell, the main consequence of going with option
(a) is that we
MUST NOT in future define a different property/relation
prov:hasprovenance, as
under some circumstances covered by RFC5988, this would be
indistinguishable
from prov:hasProvenance.
Given where we now are, my inclination would be to stay with
things as they are,
but add a note reserving the all lower-case versions of
prov:hasProvenance,
etc., from future use because of the case insensitivity comparison
requirement.
#g
--
--
--
Dr. Paul Groth (p.t.gr...@vu.nl <mailto:p.t.gr...@vu.nl>)
http://www.few.vu.nl/~pgroth/ <http://www.few.vu.nl/%7Epgroth/>
Assistant Professor
- Knowledge Representation & Reasoning Group |
Artificial Intelligence Section | Department of Computer Science
- The Network Institute
VU University Amsterdam
--
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.mor...@ecs.soton.ac.uk
United Kingdom http://www.ecs.soton.ac.uk/~lavm
