W3C home > Mailing lists > Public > public-prov-wg@w3.org > January 2013

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

From: Tom De Nies <tom.denies@ugent.be>
Date: Tue, 29 Jan 2013 14:40:35 +0100
Message-ID: <CA+=hbbd+UbGwri5JqLKME-eJzTJMDt7-TRLi-NMLC3bJaCKe9A@mail.gmail.com>
To: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
Cc: Provenance Working Group <public-prov-wg@w3.org>
Looks like I missed some things, thanks for spotting them so quickly!

>
> >> 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?
>
>
I've included this text as a note:

> Note that the use of a non-empty prefix for extensions of PROV-N is
> technically not valid. The terms used in this document can be made valid by
> the addition of a prefix "prov:" to all PROV-Dictionary terms. However,
> this would greatly reduce the readability of this document. The Working
> Group is currently discussing how to address this issue before the next
> Working Draft of this document.

here:
https://dvcs.w3.org/hg/prov/raw-file/default/dictionary/prov-dictionary.html#dictionary-notation


>
>
> > 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
> an informative link.
>
> 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.
>

Oh, I see. I missed that link.
Actually, I didn't realize it was a plain text file. We'll include a link
in the document and provide the grammar file this week, as we did with the
owl and xsd files.


>
>
> > 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.
> > http://www.w3.org/TR/prov-links/
>
> 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.
>
> I assume this is the same note as above?


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

Indeed, I missed those. Fixed.


>
> > 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)
>
>
> Correct. Man, it's been a while since I had to use EBNF grammar. I believe
they are fixed now.
I'll try to resolve the CSS issue by including the production rules from
the grammar (once we have it) as it's done in PROV-N.

>
> >> 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
>
>
Indeed, another one I missed. Thanks.

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

Yes, but I fear this will always be a point of discussion to have it in the
spec or not. There are people strongly in favor of one or the other.
I'm curious as to whether the community will express a need for this
attribute.


>
> > 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? (
>
> It should just be the owl for what's described in the document. We'll make
sure it's valid and can be used.


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

Yes, we're working on it ;)


>
> > 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].
>
> Fair enough. Fixed.

>
>
> >> 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?
>
> It's green, but nonetheless an editorial note:
http://dvcs.w3.org/hg/prov/raw-file/default/dictionary/prov-dictionary.html#dictionary-xml-schema

- Tom
Received on Tuesday, 29 January 2013 13:41:01 UTC

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