Update just pushed.
https://dvcs.w3.org/hg/prov/raw-file/tip/paq/prov-aq.html
I've updated has_provenance, has_anchor and has_query_service, as these all
appear as link relations.
Unchanged as yet, but up for discussion are
describesService
provenanceUriTemplate
that are used only in RDF service descriptions.
#g
--
On 27/02/2013 10:26, Paul Groth wrote:
ok will do.
@Graham will you update the paq?
Thanks
Paul
On Wed, Feb 27, 2013 at 10:24 AM, Luc Moreau <[email protected]>wrote:
yes Paul, no problem, I wouldn't wait till the call, I would tell all
editors now.
Luc
On 02/27/2013 10:16 AM, Paul Groth wrote:
I have this as part of the agenda item on the call tomorrow.
I'd like to decide by then.
@Luc are you ok with the underscore solution?
On Wed, Feb 27, 2013 at 10:06 AM, Ivan Herman <[email protected]> wrote:
Very honestly: I do not have strong opinion here, I can go either way.
But yes, we should decide soon.
Ivan
On Feb 27, 2013, at 11:02 , Paul Groth <[email protected]> wrote:
Have we come to a conclusion on this?
We need to decide to let people go through the staging process.
I'm in favor of prov:has_provenance . As this is a purely syntactic
change from what we already had.
cheers
Paul
On Tue, Feb 26, 2013 at 11:46 AM, Graham Klyne <[email protected]>
wrote:
I would favour prov:has_provenance over prov:hasprovenance or
prov:provenance.
I have a concern that prov:provenance reads more like a class name than
a
property/relation. Also, can we be sure that, in future, someone won't
want to
define prov:Provenance as a class of some kind? (Because of the case
insensitive matching defined by RFC5988, and arguably good practice
generally,
the capitalized form should be off-limits for future use if
prov:provenance is
selected.
#g
--
On 26/02/2013 10:51, Paul Groth wrote:
That seems to be the best way then.
so prov:hasprovenance or prov:has_provenance
?
Paul
On Tue, Feb 26, 2013 at 10:13 AM, Ivan Herman <[email protected]> wrote:
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
--
--
Dr. Paul Groth ([email protected])
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
----
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
--
--
Dr. Paul Groth ([email protected])
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
--
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
