Re: hasProvenance property name [MAYBE URGENT]

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> 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)
http://www.few.vu.nl/~pgroth/
Assistant Professor
- Knowledge Representation & Reasoning Group |
  Artificial Intelligence Section | Department of Computer Science
- The Network Institute
VU University Amsterdam