Do you mean the element that is generated into the header of the HTML? If that is the only place it appears, I think we can change that for the published PR document before handing it over to the webmaster.
Ivan On Feb 26, 2013, at 10:42 , Luc Moreau <[email protected]> wrote: > 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 > > ---- 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
