See also: IRC log
<scribe> scribenick: hknublau
Too few people attending, likely a short meeting.
<Arnaud> PROPOSED: Approve minutes of the 21 April 2016 Telecon: http://www.w3.org/2016/04/21-shapes-minutes.html
RESOLUTION: Approve minutes of the 21 April 2016 Telecon: http://www.w3.org/2016/04/21-shapes-minutes.html
<Arnaud> PROPOSED: Open ISSUE-152, ISSUE-153, ISSUE-154, ISSUE-155, ISSUE-157
<TallTed> +1
+1
jamsden: Could we in the future wrap multiple editorial issues up into a single change set?
... esp if the issue includes a suggested change
... Proposing to reject the current issues, instead doing reviews that may or may not lead to formal ISSUEs
<ericP> note that we have zillions (i checked) of emails in the archive
TallTed: Why reinventing W3C process. Not everyone is familiar with Git.
... We could use a more interactive editing tool: wikis
Arnaud: We started using GitHub, because most people/developers now use.
... W3C was blamed to be old fashioned, gave up to pressure from outside
... Being in HTML format is better for publishing
... From an issue management POV, GitHub has issue management built-in. OTOH Tracker is integrated with mailing list.
... Possible change to process, e.g. all new issues will be OPEN by default.
... On editorial issues we could agree that they don't need a formal resolution, the parties could just close if they agree outside.
... Possible downside: people may abuse this and just close issues, but in that case it can be escalated to WG.
... Tracker gives permissions to everyone in the WG to change status, it's all tracked.
... Other groups use GitHub for "simple" issues only, but that turned out to be a nightmare
TallTed: We could also just say that editorial issues don't need formal ISSUEs.
Arnaud: But how to make sure that issues have been addressed.
marky: I am a big fan of using GitHub, I could provide a quick how-to guide for GitHub techniques.
Arnaud: Pull requests can be very efficient.
hknublau: If someone raises issues it would be ideal to also have a proposal for resolving them.
... Also, it would be good to periodically go through your issues to see if they have been addressed in the meantime.
Arnaud: We could have a label [Editorial] in the subject line
jamsden: Life cycle changes in Tracker does not produce an email notification.
ericP: Correct. It's working the other way around - Tracker monitors the mailing list.
Arnaud: We could go through existing tickets and mark them as [Editorial]
kcoyle: GitHub forking does work reasonably well for editorial changes.
<Arnaud> PROPOSED: Editorial issues should have [Editorial] in the subject line and can be opened and closed by the editors and/or commenters without formal resolution from the WG
jamsden: We should encourage properly formed issues, they should have recommended changes.
+1
<TallTed> +1
<kcoyle> +1
<marky> +1
<Arnaud> ericP: +1
RESOLUTION: Editorial issues should have [Editorial] in the subject line and can be opened and closed by the editors and/or commenters without formal resolution from the WG
<jamsden> +1
RESOLUTION: Open ISSUE-152, ISSUE-153, ISSUE-154, ISSUE-155, ISSUE-157
<Arnaud> PROPOSED: Close ISSUE-126 and ISSUE-127 as no longer relevant
<kcoyle> +1
+1
<TallTed> +1
<jamsden> =1
<jamsden> +1
<Arnaud> ericP: +1
RESOLUTION: Close ISSUE-126 and ISSUE-127 as no longer relevant
<trackbot> issue-110 -- relationship between sh:constraint and sh:property and sh:inverseProperty -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/110
<Arnaud> PROPOSED: Close ISSUE-110 as addressed by the current draft
+1
<TallTed> +1
<Arnaud> ericP: +1
<kcoyle> +1
<jamsden> +1
RESOLUTION: Close ISSUE-110 as addressed by the current draft
<marky> +1
<Arnaud> issue-123
<trackbot> issue-123 -- Shall we unify the syntax of sh:directType and sh:class? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/123
hknublau: Proposing to drop sh:directType (not too relevant, problems with inferencing)
jamsden: OSLC Resource Shapes didn't do inferencing and everything was directType, but compatibility with OSLC is less relevant now.
Arnaud: Nobody seems to fight for sh:directType, we'll vote next week.
<Arnaud> issue-141
<trackbot> issue-141 -- How to represent mixed datatype-or-class ranges -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/141
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-141:_Mixed_ranges
hknublau: Proposing merging sh:datatype and sh:class to sh:type (as in emails)
<Zakim> ericP, you wanted to ask if a class constraint is the same as a property constraint on the property rdf:type
jamsden: OWL did distinguish the types of properties (Object/DatatypeProperty)
... SHACL tries to provide constraints in a particular context
... although I find the simplification appealing, but for structural query purposes I think it goes too far.
... (following discussion I am OK with this change)
ericP: Easier to have two properties sh:datatype, sh:class for static analysis
hknublau: There is also sh:nodeKind for that
Arnaud: Please go to Proposals page to cast your preference
<Arnaud> issue-92
<trackbot> issue-92 -- Should repeated properties be interpreted as additive or conjunctive? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/92
ericP: I have tried to encode a version of ShEx with strictly conjunctive semantics.
... problem: multiple constraints on the same property, and you expect them to work not strictly conjunctively
... Jose and I wanted to meet about this and make a proposal. Iovka found issues with sh:partition (e.g. putting a disjunction inside of it)
... SHACL is a bit like OWL, ShEx is more like BNF
Arnaud: We can leave it at this, waiting for ShEx people.
<jamsden> 78 is still open
<Arnaud> issue-105
<trackbot> issue-105 -- SHACL SPARQL constraints depend on namespaces in a graph, which is not defined -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/105
<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Apr/0177.html
hknublau: Explaining proposal with a property at sh:sparql to point at prefix declarations, and these declaration may extend each other.
<marky> +q
marky: Who is the audience of this simplification.
Arnaud: The author of the SHACL document
... latest proposal addresses part of the problems - explicit pointer at prefixes
jamsden: I continue to believe there are two languages here (SPARQL and SHACL) and there is no relationship between the two
... to do this properly we'd need an abstract syntax tree in RDF
TallTed: SPARQL spec defines explicitly that prefix duplicates are invalid
... SHACL engine needs to look at existing PREFIXes, just to make something that isn't a big problem a bit easier.
<ericP> to TallTed's point, "A prefix declared with the PREFIX keyword may not be re-declared in the same query."
<Arnaud> trackbot, end meeting