See also: IRC log
scribenick pfps
<Arnaud> Dimitris, are you calling back?
<Dimitris> yes, I cannot hear anything
<Arnaud> PROPOSED: Approve minutes of the 27 August Telecon: http://www.w3.org/2015/08/27-shapes-minutes.html
the minutes are a fair record of what happened
I find that the working group has been making resolutions during meeting without any advance notice.
arnaud: we cannot stopped working every time someone is absent
... the best we can do is try to make progress
... people who were absent can object to the resolutions
I object to the closing of ISSUE-74 last week even though I had expressed regrets before the agenda was sent out
RESOLUTION: Approve minutes of the 27 August Telecon: http://www.w3.org/2015/08/27-shapes-minutes.html, noting objection from Peter on resolution of ISSUE-74
arnaud: next meeting
... F2F in France, agenda has had minor changes
... remote participation will be via WebEx and IRC, as usual
there might be different codes
eric: I'll check out the situation
arnaud: ISSUE-84
<Arnaud> issue-84
<trackbot> issue-84 -- Constraint to limit IRIs of focus nodes to a given enumeration (similar to owl:oneOf) -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/84
holger: no current notion of enumerated values
... only related feature is allowed values
kcoyle: can the enumerations be anything, e.g., literals
holger: as these are for focus nodes, only IRIs make sense
kcoyle: but don't literals make sense as well
holger: no, the only thing that makes sense are IRIs, not blank nodes or literals
<Arnaud> PROPOSED: Open ISSUE-84: Allowed IRIs
<hknublau> +1
I'm fine with opening the issue
+1
<Dimitris> +1
eric: the short name should be changed
holger: if anyone has a better name, go ahead and change it
arnaud: maybe we should try to find a better name
... eric do you have a suggestion?
eric: ...
RESOLUTION: Open ISSUE-84: Constraint to limit IRIs of focus nodes to a given enumeration (similar to owl:oneOf)
eric: "an enumerated set of legal focus nodes"
arnaud: the idea was to look at the spec and see whether they think it can be publised as a FPWD
... what should be done with the feedback sent to the mailing list?
... peter is objecting to publication so putting forward a resolution now is not useful
... there have been changes to the spec since the reviews
pfps: both Arthur's and my review are for an out-of-date version of the document
... so how can the current version of the document be published?
holger: there is a frozen version that has been saved
... I am editing the current version
pfps: I'm confused as to what my review is for?
arnaud: the goal was to try to get agreement to publish a FPWD
pfps: at some point we should be publishing something and I thought that I was reviewing something that was going to be published
arnaud: do you agree with publishing what you reviewed as a FPWD
pfps: hell no
arnaud: so the process would be to determine what it would take for you to be OK with publishing the document
pfps: in my opinion there needs to be a complete rewrite of the document and a complete review
<TallTed> ack q+
arnaud: who is going to do the rewrite?
ted: we are losing the point of what this is - this is a FPWD not a candidate recommendation
... there could be a complete rewrite after first publication
... this is only a heartbeat
arnaud: it appears that peter thinks that the document is not publishable as it would turn people off for ever
pfps: my most serious comment is that I feel that the document does not reflect the state of the document
... the main example in the document uses shapes as classes, which is controversial, in my opinion
arnaud: a complete rewrite is ...
<Arnaud> not practical
pfps: I spent a lot of time looking at the document and found lots of problems - I don't think that the document reflects the thinking of the working group, the document has lots of technical flaws, and it does not present an understandable view of SHACL
holger: ...
arnaud: anyone is welcome to create a branch and make changes
pfps: yes, having more people contribute to the document would be useful
arnaud: who is going to do the rewrite?
pfps: I'm not going to do it.
... I've done a review of the document and put forward a number of changes that I think are needed and a number of flaws that I see in it
arnaud: at the F2F meeting there will be a proposal to publish a FPWD
... we have to move forward
holger: what is the working group being asked to do?
scribe comment - I think that arnaud was asking for the working group to look at the reviews but I didn't get a chance to scribe that
holger: I have made a number of changes to address comments
... right now I am using pseudo code but Arthur had a comment on that
... is there another way of doing things
arnaud: any suggestions?
pfps: in many papers I have seen the English description is better than the pseudo code
holger: how about Java script?
pfps: the problem is having the right level of specificity
arnaud: that is why pseudo code is often used
... there is no good answer - the only way forward is to choose the least worse
... you could change a small part and pass it by Arthur
holger: I'll experiment, but that is not going to happen by next week
arnaud: we will come back to this at the F2F
<TallTed> issue-70?
<trackbot> issue-70 -- special treatment of blank node types -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/70
pfps: I would like any language that the working group proposes to be as simple as possible so special treatment of certain kinds of nodes needs strong justification
holger: from my perspective the most important aspect is usability - the language needs to look attractive - I would be OK with not requiring type triples at all
<hknublau> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Aug/0155.html
holger: I find the JSON-LD syntax to be quite reasonable
arnaud: [summarize the two points of view]
... any other comments?
... from others
... if you really want something simple to write you can use the user-friendly syntax
holger: if we had that syntax ...
arnaud: the fact that we don't have the user-friendly syntax makes this call harder
<kcoyle> don;t understand
holger: what about making the type triple optional
pfps: I'm not against that, but are there other problems?
holger: if people share IRIs then it would be helpful to have the type triple
pfps: I would go along with that
arnaud: maybe a warning that omitting the type arc might sometimes cause problems
<hknublau> Proposal: For the properties marked with a sh:defaultValueType, the rdf:type triple is optional (to the engine). For IRIs, the recommendation will be to have a type triple (a SHOULD).
pfps: I don't know if I understand this proposal
Proposed: type triples are optional whenever they can be deteremined
holger: I think that there needs to be a sh:defaultValueType to make sense of the proposal
pfps: I think that a crisper proposal is needed
arnaud: agree
<TallTed> PROPOSED: rdf:type statements SHOULD be included whenever possible, but they are optional. omitting rdf:type statements may have various negative effects, so their inclusion is strongly recommended.
holger: I don't like SHOULD on blank nodes
... I'll try to work out something
<Arnaud> PROPOSED: Close ISSUE-70, stating that rdf:type statements SHOULD be included whenever possible, but they are optional. omitting rdf:type statements may have various negative effects, so their inclusion is strongly recommended for IRIs.
PROPOSED: Close ISSUE-70, stating that rdf:type statements are optional but SHOULD be included whenever possible on IRI nodes. omitting rdf:type statements may have various negative effects, so their inclusion is strongly recommended for IRIs.
... Close ISSUE-70, stating that rdf:type statements are optional but SHOULD be included whenever possible on IRI nodes. omitting rdf:type statements may have various negative effects
<TallTed> +1
<kcoyle> +1
+1
<hknublau> +1
<Dimitris> +1
<ericP> +0
RESOLUTION: Close ISSUE-70, stating that rdf:type statements are optional but SHOULD be included whenever possible on IRI nodes. omitting rdf:type statements may have various negative effects
<trackbot> ISSUE-51 -- What types of validation results should be returned -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/51
<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Aug/0157.html
arnaud: holger put together a proposal trying to be between something that it too simple and something that is too complex
pfps: are there meta-classes involved?
holger: no
pfps: sorry, I misread
kcoyle: my concern is that the validation result was not returning anything for success
holger: there are success results - an API would have a boolean
...
arnaud: karen are you simply asking for something that says that no error was found? this would be a boolean result in the API
holger: the API has such a boolean, which is supported by the data model
ted: i've seen success with information ...
holger: you can determine the result from looking at the data produced
ted: successresult and validationresult are both success results - one has more information than the other
holger: there should be some distinction between errors and non-errors
ted: drop sucessresult and use non-error validationresult
dimitris: there can be multiple success results and multiple failure results
ted: validationresult would be better as constraintresult
arnaud: we are out of time
holger: success results are at the shape level - validation results are at the focus node level
arnaud: we will look at this next week - people can come up with proposals
... the goal for next week is to close as many issues as possible - we need to make progress
... people should read the reviews of the draft
... there are still issues with nomenclature
<TallTed> the different levels of success/failure need different levels of messaging. overall success/failure of a shape validation is comprised of many success/failures of constraints within the shape. each constraint might produce pure-success/success-with-info/error (but need not produce success output).
<Arnaud> trackbot, end meeting