W3C

RDF Data Shapes Working Group Teleconference

03 Sep 2015

Agenda

See also: IRC log

Attendees

Present
Arnaud, kcoyle, pfps, hknublau, ericp, TallTed, Dimitris
Regrets
aryman, simonstey
Chair
Arnaud
Scribe
pfps

Contents


scribenick pfps

<Arnaud> Dimitris, are you calling back?

<Dimitris> yes, I cannot hear anything

Admin

<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

Disposal of Raised Issues

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"

SHACL Spec Review

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

ISSUE-70: blank node default type

<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

ISSUE-51

<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

Summary of Action Items

Summary of Resolutions

  1. 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
  2. Open ISSUE-84: Constraint to limit IRIs of focus nodes to a given enumeration (similar to owl:oneOf)
  3. 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
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2015/09/17 20:41:14 $