It's in the <link> element we added last week.
On 26/02/2013 09:40, Ivan Herman wrote:
Graham,
I am not sure I understand something.
I have looked at the prov-o document, and that document does not mention the
prov:hasProvenance term. Ie, where does this term appear in any of the four
Rec-track documents? More importantly, does it appear, if it does, in a
normative section?
Ivan
On Feb 26, 2013, at 10:30 , Graham Klyne<[email protected]> 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
--
----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf
--
Professor Luc Moreau
Electronics and Computer Science tel: +44 23 8059 4487
University of Southampton fax: +44 23 8059 2865
Southampton SO17 1BJ email: [email protected]
United Kingdom http://www.ecs.soton.ac.uk/~lavm
