Re: hasProvenance property name [MAYBE URGENT]

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 <GK@ninebynine.org 
> <mailto:GK@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.groth@vu.nl <mailto:p.t.groth@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.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm