# Re: PROV-DICTIONARY internal review for first public working draft (ISSUE-614)

From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
Date: Tue, 29 Jan 2013 12:50:25 +0000
Message-ID: <CAPRnXtkpy3xqeZke0VSTKfKxhEuOKV4EApe+xH-J9TMXQn7OUA@mail.gmail.com>
To: Tom De Nies <tom.denies@ugent.be>
Cc: Provenance Working Group <public-prov-wg@w3.org>
Thanks for addressing almost all of my comments! The document now
reads very well. See below for response and a few glitches.

On Tue, Jan 29, 2013 at 11:59 AM, Tom De Nies <tom.denies@ugent.be> wrote:

> IF hadMember(d, e) and 'Dictionary' \in typeOf(d) THEN
> hadDictionaryMember(d, e, "k") with k and unknown key.
> I suggest we leave this out for this draft, and make it a formal issue,
> which we can discuss as a group before the next draft.

Agreed.

>> The notation used for dictionaries in this document extends the standard
>> PROV-N according to the principles described in the PROV-N extensibility
>> chapter. However, because dictionaries are defined in the same namespace as
>> the rest of PROV-N, the terms in this document do not have a non-empty
>> prefix. For the remainder of this document, we will assume that the default
>> namespace http://www.w3.org/ns/prov# is used, and thus, no prefix is
>> specified for the terms associated with dictionaries.
> Is this acceptable to you?

Perhaps - for this First Public Working Draft, as we discussed in last
week's call.

The PROV-N does not allow the usage of the empty prefix , so it's
still not technically valid:

> Expressions compatible with the extensibilityExpression production follow a general form of functional syntax, in which the predicate must be a qualifiedName with a non-empty prefix.

Insert one of those yellow editorial boxes about this not being
technically valid and that the WG is planning on addressing this issue
for the next draft?

> We noticed that although there is a grammar folder on the mercurial
> repository, PROV-N currently does not link to a downloadable grammar either.
> (or we couldn't find the link).
> We suggest that we wait until PROV-N does this in the final spec, and then
> conform to that when we link to it in the next draft.

PROV-N links to it like this:

> 1.2 Compliance with this Document
> Productions (displayed in boxes) are normative, as opposed to the separate [file] grouping all productions for convenience of programmers, which is informative.
> [file] -> http://www.w3.org/TR/prov-n/grammar.txt

Yes, the link "file" is not very obvious here, but it is published as

But OK, we can skip the grammar link for the FPWD as long as we don't
forget this for later - add an appropriate TODO.

> See the text added to the beginning of the PROV-N section, and our response
> to 8a. Does this remain a blocking issue for you now that this text is
> included? I'd like to remark that PROV-LINKS does not declare this namespace
> either, and is published as a working draft.

Arghs, the precedence argument! OK for this draft then (given a yellow
box noting this issue properly) - but this must really be addressed
later. It does look quite inconsistent if our own extensions are not
valid.

>> 11) "key" is not a defined Non-Terminal - neither here nor in PROV-N
>> document or grammar.
>>
>> "dIdentifier" is similarly a new non-Terminal that must be defined
>> here. (presumably it is an entity which is a prov:Dictionary type).
> Fixed (after previous reviews). Could you check the expressions again? I
> believe everything should be linked and defined correctly now.

All checked and be OK, except for the link for keyValuePair and "key" in:

> keyValuePairs ::= keyValuePair ( "," keyValuePair )*
> keyValuePair ::= ( key , eIdentifier )
> keySet ::= key ( "," key )*

Here the hyperlinks go to PROV-N when they should be local.

> Now uses double quotes.

All good, except for in the new 3.5 Other expressions where there are
for some reason additional "s around non-terminals.

For instance:

> dIdentifier ::= "identifier"
> keyValuePairs ::= "keyValuePair ( "," keyValuePair )*"

I think you mean:

> dIdentifier ::= identifier
> keyValuePairs ::= keyValuePair ( "," keyValuePair )*

etc.  (I can't show all of these here because of the CSS issue)

> This appears to be because the quotes are added through CSS. I noticed that
> in PROV-N, this is done differently now, and the expressions are pulled from
> the grammar by a javascript script that runs on the page. We will fix this
> when we create the grammar document.

OK for now then.

>> 15) Non-Terminals not matching table below: identifier,
>> keyValuePairs, optional-attribute-values
>> Change to match table.
> Fixed (after previous reviews). Could you check the expressions again? I
> believe everything should be linked and defined correctly now.

This still needs fixing:

> membershipExpression ::= hadDictionaryMember ( dIdentifier , entity , key )

entity -> eIdentifier

>> Remember that for keyValuePairs the first pair is not optional.
> Fixed (after previous reviews). Could you check the expressions again? I
> believe everything should be linked and defined correctly now.

keyValuePairs definition loooks OK. (except for the thing with the " above)

>> Note that the complete content of a dictionary is unknown unless it can be
>> traced back to an empty dictionary through a series of insertions and
>> removals. If an asserter wants to explicitly state that a dictionary is
>> empty, it is recommended that the prov:type prov:EmptyCollection is used.
> Is this ok for you?

Yes - although I miss being able to simply state "these are all the
members" (the old hadmembers complete)

> Sam and I discussed this, and came to the following conclusion. While it is
> true that this syntax is quite verbose, it is also the only one that is 100%
> clear and cannot induce confusion or discussion. This, and the fact that the
> other reviewers did not see a problem with this property has made us decide
> that this is the safest choice, and we will keep it. If you consider it a
> serious problem, we can discuss it as an issue for the next draft.

OK.

> As discussed on the call, we included a link to the owl file in the
> document, but the file itself might still be updated. (we linked to the raw
> "editor's draft" version, to allow ourselves some time to update and verify
> the owl syntax.)

OK. So you want comments on the OWL files separately then? (

> I''ve also included the text you asked for:
> (..)
> Is this text acceptable to you?

I hope so! ;)

> We've included the link. XSD schema will actually be there today. Again, we
> point to the editors space, to allow corrections after publication of the
> document.

OK.. it's a bit empty now (<xml></xml> !)

> The XML schema for PROV-Dictionary is available for download [here]
> The owl-file of PROV-Dictionary is available for download [here]

Also please, never, anywhere, use the hyperlink "here".

See point 2 at http://www.nngroup.com/articles/top-ten-web-design-mistakes-of-2005/
(2005!)

Rephrase to something like:

"You may download the [XML schema for PROV-Dictionary].
"You may download the [OWL file for PROV-Dictionary].

>> 39) Provide download link for XML schema - also include usage
>> instructions as per imports etc. (equivalent as for OWL imports above)
> Done.

Could we add a yellow box to remind ourself to also explain how to use this?

>> ==== END OF REVIEW ===
>> Now relax..! :)
> I'll try. Is this a blocking issue? ;)

Yes!

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

Received on Tuesday, 29 January 2013 12:51:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:28 UTC