See also: IRC log
<scribe> scribenick: TallTed
<Arnaud> PROPOSED: Approve minutes of the 26 May 2016 Telecon: http://www.w3.org/2016/05/26-shapes-minutes.html
RESOLUTION: Approve minutes of the 26 May 2016 Telecon: http://www.w3.org/2016/05/26-shapes-minutes.html
<pfps> minutes OK by me
<pfps> what has been changed so far?
Arnaud: what's missing to resolve this?
hknublau: this depends on ISSUE-133, discussion of sh:constraints syntax
<ericP> issue 135 proposals
https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-135:_and.2For_syntactic_sugar
pfps: there's a proposal to allow triple expressions. does anyone aside from the proposer think that's relevant here?
... that looks like a major change, and I wonder whether it solves this issue
ericP: suggests this is an easy(?) way to make comprehensible nesting of ANDs, ORs, etc.
<pfps> A quick look at http://w3c.github.io/data-shapes/shacl/#OrConstraintComponent and the equivalent for sh:and would show that the same wording is used for the things that can go inside both and and or. Admittedly there is not a real formal gramar for SHACL, but what is there is the same.
<pfps> The fact that a working group member is unsure what the top-level syntax for shapes is is a very bad sign for the working group.
hknublau: it seems that currently a shape is an intersection of constraints; we might also want to allow it to be a union; which would let everything fall together nicely...
<Zakim> ericP, you wanted to ask what a CLOSED inside a non-CLOSED means
<pfps> The proposed syntax does not allow shapes to be embedded in other shapes - this is the MAIN difference.
<pfps> There are lots of other differences, such as requiring mins and maxs for every triple constraint
<pfps> The difference is that this proposal is shapes containing constraints containing constraints containing ...
ericP: one goal was to make CLOSEDness only a top-level, shape-level thing
<pfps> The current syntax is shapes containing constraints containing shapes containing constraints containing ...
hknublau: I don't think this is actually really different than what we have in SHACL. I don't like the abstract grammar. I prefer we use RDF.
<pfps> The other proposal has (constraints and sometimes shapes) instead of constraints
Arnaud: I hope this has helped people understand the proposal, think about it, cast your vote on the proposals page
<Arnaud> issue-148
<trackbot> issue-148 -- non-uniform syntax in scopes -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/148
Arnaud: we discussed this last week and addressed one of the two problems we have to address
... let's talk about allsubject and allobjects scopes
<marqh> +present
<pfps> So requiring SPARQL for scoping all nodes doesn't seem to be so bad for me.
<pfps> However, these were addded because someone wanted them.
hknublau: perhaps we should drop all{Subjects,Objects}
... I haven't found them to be useful, last time Dimitris said he might have a use case but it wasn't clear
pfps: if we have all{Subjects,Objects}, it seems we should have allNodes as well
hknublau: and allPredicates, where do you stop?
kcoyle: there wasn't a specific use case that spawned this, but there was a desire for a generalized broadened scope
<pfps> all dc:title literal can be done using property scopes
<pfps> if you want decent validation messages then you would has a scope of all subjects of dc:title and then require of them that all their values for dc:title are literals
<pfps> So I would be happy to completely remove these, but I would not be happy to have them just move to the advanced stuff
ericP: we have hasClass, which looks for rdf:type predicate with object of your specific... maybe we want a template where you provide a predicate and either subject or object, which looks for everything in the missing position?
<Arnaud> PROPOSED: Delete AllObjectsScope and AllSubjectsScope from Core, leave this to be handled using the extension mechanism
<ericP> 0
<hknublau> +1
<pfps> +1, as long as this syntax doesn't just end up in the advanced section
<kcoyle> +1
PROPOSED: Delete AllObjectsScope and AllSubjectsScope from Core, not to become Advanced. Anyone who wants this functionality is left to write their own SPARQL.
<pfps> +1
<hknublau> +1
<hsolbrig> +1
+1
<kcoyle> +1
<ericP> +0
RESOLUTION: Delete AllObjectsScope and AllSubjectsScope from Core, not to become Advanced. Anyone who wants this functionality is left to write their own SPARQL.
<hsolbrig> the identity vote
<Arnaud> PROPOSED: Close ISSUE-148, resolved given previous resolutions
<hknublau> +1
+1
<pfps> +1
<ericP> +1
<hsolbrig> +1
<kcoyle> +1
RESOLUTION: Close ISSUE-148, resolved given previous resolutions
ISSUE-139?
see https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-139:_Universal_applicability
<trackbot> ISSUE-139 -- Can all constraint properties be applied in all scenarios? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/139
<hsolbrig> pfps: vote must be a group
pfps: Bell Labs unix philosophy is to permit anything that might be reasonable, that doesn't actually cause problems, because it may become useful...
hknublau: some things have practical value/impact, e.g., hasValue has different impact as nodeConstraint than as propertyConstraint...
Arnaud: we extended SHACL to address specific use cases, and wound up with many special case syntaxes.
... pfps is suggesting making a simpler pattern, to be applied in multiple cases, which may lead to people doing "stupid" things, but that's no different than any other language...
kcoyle: I think SHACL sometimes reads like a description of an implementation rather a language
... if there are problems with implementation we should address these in notes or something specific to the implementation
... ... but not make that part of the defination of the language
<pfps> It would also be nice to hear from someone who has implemented a SPARQL system that allows literals as subject.
hknublau: it's not true that programming languages allow everything, there are all sorts of constraints like typing etc that limit the language
<pfps> I don't believe that anyone is arguing that languages should allow everything.
hknublau: of course it's possible to implement this in Core but how are we going to support this in the SPARQL exention?
<pfps> The particular case is known when the constraint component code is being generated.
pfps: this proposal is just asking why have exclusions in this table of what can be done. we do permit things like `AND (a, a)` which is obviously silly... why go to the effort of forbidding other silly things?
<Arnaud> http://w3c.github.io/data-shapes/shacl/#constraints
hknublau: my original point remains that I don't see any value in making this change which allows for meaningless constructs
TallTed: testing whether `1 = 1` is silly, but every programming language lets you do it. it causes no problem; it should be permitted.
... a generic syntax makes much easier for front-end users (possibly not for back-end developers). unless it makes something near- or impossible to implement, that generic syntax is worth striving for.
hknublau: I think this is a mistake, it would move us backward rather than forward
<Arnaud> STRAWPOLL: Should we generalize the syntax along what peter is proposing to do with allowing constraint properties to be applied more broadly?
<hknublau> -1
<kcoyle> +1
<pfps> In SHACL it is already the case that things like sh:minExclusive have to handle things like ex:john > 1 because property constraints can have either IRIs or literals as value nodes.
<pfps> +1
<ericP> +1
+1
<marqh> ... 0
<kcoyle> harold's gone
<hknublau> Dimitris and Simon are missing too
Arnaud: the majority present seems to lean in favor of generalizing the syntax so we will need to spend more time on this
<Arnaud> trackbot, end meeting