See also: IRC log
<scribe> scribenick: kcoyle
<Labra> ** I am attending another meeting...
<Labra> ** I can see the IRC, but no audio
<Arnaud> PROPOSED: Approve minutes of the 3 March 2016 Telecon: http://www.w3.org/2016/03/03-shapes-minutes.html
<pfps> minutes look fine to me
RESOLUTION: Approve minutes of the 3 March 2016 Telecon: http://www.w3.org/2016/03/03-shapes-minutes.html
raised issues: 124-133
124-133
<Arnaud> PROPOSED: Open ISSUE-124 sh:group, ISSUE-125 sh:NodeConstraint missing, ISSUE-126 sh:TemplateConstraint undefined, ISSUE-127 sh:TemplateScope undefined, ISSUE-128 rdfs:range, ISSUE-129 existential constraints, ISSUE-130 rdf dataset assumption, ISSUE-131 sh:hasShape ill defined, ISSUE-132 sh:predicate in constraints, ISSUE-133 syntax
jamsden: given issue 95 and the scope of these - what are we evaluating these against, vis a vis issue 95
Arnaud: yes, there is definitely some overlap
ericP: perhaps Peter could winnow down the list?
... e.g. proposal for metadata simplification; and 133 syntax simplification
pfps: 125-128 may be redundant with 95
ericP: 133?
pfps: many are issues in the current SHACL spec document, things that aren't well defined
... this could just be a fix to the document, or something can be added
... so in that sense they are not redundant because they are about the document
ericP: there are proposals in many of them
pfps: 128 has a proposal, those before that do not;
Arnaud: there are broad issues like 95 and 133 that will impact the others; but having a useful of gaps in the spec is useful
... we will try to address big issues forst then we can look back at the gaps tos ee if they still exist
jamsden: my question was related to how we go about evaluating the issues; some that are closed may need to be reopened
TallTed: for the moment, these are issues; we will evaluate them in another step; some issues may be reopened
Arnaud: all proposals are proposals; anyone can bring up anything for discussion
<TallTed> +1 open the set
<Dimitris> +1 to open all as well
<pfps> +1
+1
<jamsden> +1
<hknublau> +1
<Labra> +1
<ericP> +q
<ericP> +1
RESOLUTION: Open ISSUE-124 sh:group, ISSUE-125 sh:NodeConstraint missing, ISSUE-126 sh:TemplateConstraint undefined, ISSUE-127 sh:TemplateScope undefined, ISSUE-128 rdfs:range, ISSUE-129 existential constraints, ISSUE-130 rdf dataset assumption, ISSUE-131 sh:hasShape ill defined, ISSUE-132 sh:predicate in constraints, ISSUE-133 syntax
<trackbot> ISSUE-99 -- special treatment of rdfs:Resource and rdf:List in sh:valueClass (and possibly elsewhere) -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/99
Arnaud: ended last time with a proposal to rename; kcoyle objected
<pfps> I took a look at the current draft, and it appears that things are good wrt rdfs:Resource and rdf:List
Arnaud: option: forget about the renaming... can we close 99? or do we want to discuss the names of the terms
... proposal to rename can be done at any time
<Arnaud> PROPOSED: Close ISSUE-99, based on the related resolutions from 3 March 2016
+1
<ericP> +0
<hknublau> +1
<pfps> +1
<Dimitris> +1
<TallTed> +1
<jamsden> +1
RESOLUTION: Close ISSUE-99, based on the related resolutions from 3 March 2016
<trackbot> ISSUE-80 -- Constraint to limit IRIs against scheme/namespace, possibly with dereferencing -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/80
ericP: email gives view of ShEx model on stemming; thinks feature is useful
<pfps> I was also going to say that this is redundant
ericP: easier than "is URI ..." - is redundant with SCHACL, but still useful
... ShEx = any URL, has stem, or stem "-stem" -- not... sometimes have to look at type; bnodes
<pfps> stem "X" = nodeKind IRI & pattern "X*", right?
Arnaud: we know it's redundant; if we feel it is useful we can add it to the spec. Eric's email shows what it could be
<pfps> do we have a definition of all these cases?
ericP: stem -stem and stem- url may not be redundant because of use of not
<Dimitris> I would rename it to sh:ns or sh:namespace
kcoyle - very common
TallTed: what is the way to do this now? vs. what could be new
<pfps> pointer to the email?
Arnaud: could someone create examples of both for comparison?
ericP: the question is stem - stem - can you do that?
pfps: write that down somewhere
<TallTed> "this but not that" no?
Arnaud: eric please follow up to email, show what can be done in SHACL and highlight the -stem feature
<trackbot> ISSUE-68 -- pre-binding not defined in SHACL spec -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/68
<pfps> stem - stem2 would be pattern "stem*" & ! pattern "stem2*"
Arnaud: history; Holger added to spec, followed by email thread discussion; possibly problem not solved; can we converge here today?
hknublau: talking with Andy to understand how this might be formally described; not described so yet
... question: how much detial is needed?
... may need special handling for "minus"
... very complicated so takes a lot of time
pfps: section added to spec inadequate
... spec depends on hasShape, and doesn't work; not even clear what it is supposed to be doing
hknublau: need to find someone inthe working group to work on this
pfps: can't work on it until
... it's clear what is supposed to be doing
hknublau: it is variable substitution
pfps: what implementations exist for sh:hasShape
Arnaud: there are two issues: pre-binding and sh:hasShape
pfps: prebinding is required ... sh:hasShape goes outsid eof sparql and back in; when it goes back in the enviornment needs to be applied
... pre-binding is required for return' may be the only place where this happens, which is why pre-binding relates to sh:hasShape
Dimitris: for the rest, what is described is adequate... no problems with pre-binding
section 6.2.2.1 of editor's draft
<Arnaud> 6.2.1
pfps: breaks in subqueries, and breaks in minus, and skolemization is problematic
hknublau: there is an algorithym for skolemization, but may need more to handle minus
pfps: sparql code runs different on skolemized and non-skolemized graphs
... conversion to string is a problem
hknublau: make it an appendix
pfps: no, this is a core part of the language
ericP: SPARQL 1.1 spec didn't deal with bnodes because there weren't told blank node bindings in sparql (?)
hknublau: will continue in email
Dimitris: could try to do it, in the future
Arnaud: some of this done under issue-95; Peter has now come up with an alternative syntax; where do we stand?
pfps: seems there is still disagreement with the metamodel; can we cut down the syntactic categories, and cut down the model
... and end up with a language that is easier for users
... 1) is the current language too complicated?
... 2) canw e cut it down? we can cut down the syntax
... 3) can we implement this? there are some problems; this requires a change to the implementation strategy
... could require a different extention to SPARQL
...
... don'r really need to put 'thas in
to put paths in
<jamsden> can we quantify the complexity of the syntax?
pfps: if we had had a completed design this wouldn't be a good idea; but we are not nearly done; model is not consistent today
<Zakim> ericP, you wanted to ask for vocab
ericP: want more from Peter re: actual design
<hknublau> For repeated values, just use sh:and
pfps: highlights: 1) currently you can't do sh:person; sh:partient - this is illegal because you cannot repeate constructs; what makes them difficult is pattern and qualified cardinality
... that will be hard to explain to user
... three different kinds of constraints, and 15 or 20 different pieces of which goes where - have to look up in a table
... but itisn't clear why these are separate; so why not allow them all?
... no longer have three kinds of constraints, and merge them into shapes so no diff. between shapes and constraints
... more technical: the way that you declare validation reports depends on where you are (but currently doesnt)
... validation for sh:in not s p o -- but in can be without a p
<ericP> ➕① to pfps's simplications -- i think they'll be expected
pfps: why not use two sh:class one after the other? this drives a major change to the design, which is why I defined "filler"
hknublau: some things just don't work; spec hasn't been updated because metamodel work was ongoing
... proposal #3 is clearer than the old version of the spec
... the simplification, however, doesn't work; you can use 'and' or repeat properties
... some things appear to be disadvantages, such as using position in lists
pfps: what are the other issues?
hknublau: this could take two months; path expressions - might be achieved in another way
... syntax of nested shapes is complicated, esp. and, or. Shortcut could be applied, but with a different solution. These are incremental.
<Zakim> ericP, you wanted to ask (for probably the eleventeenth clarification) about OWL parsing from RDF graphs
ericP: asking Peter - want to be able to stack constraints; how did OWL deal with this?
pfps: I prefer the way that OWL does it, but may not work in this case. Implicit AND has been gone for a long time
... means that you end up repeating the path
ericP: what if triple constraint had a value expression, and all was put into the value expression with the ands and ors
pfps: that is basically the OWL solution.... for an explicity AND is OWLish; so filler can take a structure a node with two things hanging off of it
Arnaud: question is - Peter says the model isn't regular; Holger says this is going to take months to resolve
<ericP> <S> sh:constraint [ a sh:TripleConstraint; sh:predicate <foo>; sh:expr [ a sh:And; sh:left [...], sh:right [...] ] .
<ericP> @pfps, like that?
Arnaud: we need to gather examples so that we can compare the two
... we do have the test suite that we should use for this
kcoyle: need uninvolved folks' opinions; dcmi will have a full set of examples soon
<ericP> DCMI tests
jamsden: how OSLC will migrate to shacl - already has rich use cases of shapes; volunteers to re-express them as shacl; but doesn't understand enough
... not clear how stale the current spec is; quite a bit of effort to contrast all of the different proposals
Arnaud: Encourage you to try; and provide examples, and ask for help where the questions are
<pfps> Sure
jamsden: to Peter and Holger: please do final review of proposals. then Jim will try to convert OSLC shapes to those
hknublau: proposal 3 & 4 is apples and oranges; proposal 3 is about the metamodel; syntax changes aren't in there
... what about the other approach; looking at simplifying constraints and adding paths; otherwise we are blocked and nothing else gets done
... also, we can look at the issues brought up by Peter then there is an incremental path
Arnaud: This doesn't need to stop the discussion on issue 95; should progress
hknublau: Peter's approach will end up being like proposal #3
... work is blocked
pfps: no, work goes on in other areas
... There are many technical issues still that need work, and have been on our list for a while
<pfps> If there had been something that was close to being done, I would not have proposed a change
<Arnaud> trackbot, end meeting