Re: hasProvenance property name [MAYBE URGENT]

Why is this an urgent issue..? PROV-AQ is not to be released as
Proposed Recommendation. Is prov:hasProvenance mentioned in PROV-DM,
PROV-N, PROV-O or PROV-Constraints ?


I think we should fix it now, ie. option (b), to prov:has_provenance,
prov:has_query_service, prov:has_anchor,  etc.





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
> --



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Tuesday, 26 February 2013 09:43:18 UTC