See also: IRC log
<Arnaud> scribe: kcoyle
<Arnaud> PROPOSED: Approve minutes of the 5 May 2016 Telecon: http://www.w3.org/2016/05/05-shapes-minutes.html
yes
<Dimitris> yes
<TallTed> they look like minutes...
RESOLUTION: Approve minutes of the 5 May 2016 Telecon: http://www.w3.org/2016/05/05-shapes-minutes.html
<Arnaud> PROPOSED: Open ISSUE-160
<Dimitris> +1
<TallTed> +1
+1
<hknublau> +1
<simonstey> +1
<Labra> +1
<ericP> +1
RESOLUTION: Open ISSUE-160
Arnaud: get an update from editors - lots of discussion of new terminology seciton
hknublau: Currently in limbo; good idea to have terminology section; needs to be clear, though. Has been asking for alternative terms
... esp. around terms class, instance. Perhaps "shacl class" "shacl instance'
Arnaud: still being actively worked on? or ready to go?
<simonstey> +q
hknublau: Not consistent at this point. Will take more work because "instance' for example is used all over
<Dimitris> +q
hknublau: So far no other suggestions than adding SHACL
simonstey: We might be vulnerable to comments if we publish it as is without fixing this, then that will bring criticism
... needs to be well-defined for next publication cycle, or left out altogether
... perhaps not include terminology section for next cycle; or only include those we are sure of
Dimitris: compromise: use linking instead of adding SHACL (makes document hard to read)
Dimitris - you need to mute because we are getting echo
TallTed: Working drafts are not carved in stone; having a disclaimer is ok; working draft is a heartbeat; and to get feedback from outside
Arnaud: should be at least coherent for the WD - if terminology doesn't make sense, maybe we shouldn't include it
hknublau: goal of terminology section makes it easier to rename things later; every usage would be linked to definition,
... Not possible to delete terminology seciton now - things are integrated into it
Arnaud: Should try to have something that makes sense
hknublau: Set a deadline? e.g. next week?
Arnaud: Status quo is draft today; others need to make proposals on terminology section; otherwise will stay how it is.
hknublau: could split the document and put in hyperlinks - perhaps in a few days
Arnaud: either next week or the one after
<trackbot> ISSUE-141 -- How to represent mixed datatype-or-class ranges -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/141
hknublau: currently have dataType and datatypeIn; class, and classIn. Disjoint. OWL and others have only one property for these
... three proposals (in issue document); would be good to have this before publication
... if value of type is one of known
... types, would be a datatype property; else would be a class
Dimitris: if simplify, makes ... unknown datatypes
hknublau: alternative would be to check for user-defined datatypes; not not used often so not needed for core
... needs to be easy to use for schema.org where the 'or' is used a lot
Arnaud: there's a separate issue for OR and for sh:shape; what needs to be done?
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-141:_Mixed_ranges
hknublau: proposal 3 has three options; peter and holger are ok with this
simonstey: voted on a - b and c were added later
hknublau: separate of sh:class and sh:datatype makes it easy to see what kind of datatype one has; but if you have to look at shapes or data graph, then it's harder
... don't need to cover user-defined data types because rare
ericP: sparql doesn't support comparisons of custom data types, but you can do graph patterns on them. This is used.
... if you mix class and datatype in the same property, and you are validating, you can see what it has;
... but if you are generating web forms, how do you prompt for the data if it's either/or?
hknublau: form builder would look for data type
ericP: if it's a known sparql datatype, then you can do this; but if there's a custom type,you couldn't prompt the user for the correct type
hknublau: that's ok if people want them in the core. that would be 3a
Dimitris: there's no way for shacl to know to ask for either a datatype or a class
hknublau: in 3a you would have to declare it with a types triple
Arnaud: seems to be a preference for 3a
jamsden; no opinion on 3b 3c; 3a seems fine
TallTed: it must be a known datatype or an rdf:type statement that makes it known
<Dimitris> I would prefer 0 (do nothing) or if we selected one of 3*, 3c looks better than the other two
hknublau: known datatypes are the XML ones; otherwise its under the control of the shapes graph
TallTed: shapes graph must be a complete defined/shaped ontology
Arnaud: what about doing nothing?
kcoyle: put off until after WD?
Arnaud: obvious preference for 3a; will be on agenda for next week
... others can still be considered
TallTed: issue page is out of date; needs to be updated, esp. examples
... other option: close this issue and open new one that is up to date
... decision; modify and put note at the top that it has changed. Holger will do.
<trackbot> ISSUE-78 -- Should SHACL support marking classes as abstract -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/78
jamsden: I didn't fully understand Holger's issues; I've said my piece; up to Holger if it can be implemented
hknublau: I proposed th eoriginal feature; I favor the use case, but I don't see a solution that works because of weak link between classes and shapes
jamsden: link is weak?
hknublau: if you narrow to sh:scopeClass; but you can link instances to other scopes, and should apply to those; so it becomes too narrow
jamsden: ok, see that there are other examples where it doesn't work as easily
... not ok with things that impact rdf and rdfschema
<Arnaud> PROPOSED: Close ISSUE-78, dropping sh:abstract
<jamsden> +1
<Dimitris> +1
+1
<TallTed> +1
<Labra> +1
<simonstey> +1
<hknublau> +1 (sadly)
<ericP> +1 (ambivalently)
RESOLUTION: Close ISSUE-78, dropping sh:abstract
<ericP> +ε ?
<trackbot> ISSUE-135 -- Should sh:and/sh:or/sh:not/sh:valueShape support constraints too? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/135
<ericP> issue-135
<trackbot> issue-135 -- Should sh:and/sh:or/sh:not/sh:valueShape support constraints too? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/135
<Arnaud> chair: ericP
<ericP> proposals
hknublau: introduction -> simplify syntax so do not have to point to a shape inside an or; seems not worth it
... first, need to generalize sh:or sh:not so they can also be used as property constraints (not justn ode constraints)
... so, that's the proposal: extend
... e.g. address is either a string or an instance (mixed range)
... this means you do not have to repeat the predicate
... end up with too many options to express the same thing - leads to confusion and difficulty
... proposal is to extend context of sh:or to also be allowed in property and inverse property constraints
<simonstey> +q
simonstey: this is for or, not, and (clarifying)
ericP: shex does this with an expression at the far end of a triple constraint where you can have an expression of arbitrary complexity
hknublau: that's a very different syntax; too different from what we currently have
<hknublau> ex:MyShape a sh:Shape ; sh:property [ sh:predicate schema:address ; sh:or ( [ sh:constraint [ sh:datatype xsd:string ] ] [ sh:constraint [ sh:class schema:Address ]] ) ] .
<ericP> ex:MyShape a sh:Shape ;
<ericP> sh:property [
<ericP> sh:predicate schema:address ;
<ericP> sh:or (
<ericP> [ sh:constraint [sh:datatype xsd:string ] ]
<ericP> [ sh:constraint [ sh:class schema:Address ] ]
<ericP> )
<ericP> ] .
<ericP> --done--
Dimitris: does his affect proposal relating to sh:constraint?
hknublau: No, no affect
<ericP> hknublau: this proposal leaves the door open to further simplifications
ericP: can vote w/o Peter because leaves open possibility of more revision.
<simonstey> +q
hknublau: issue can be left open
simonstey: seconding solution
<Dimitris> I also agree
hknublau: added property constraints and inverse prop constraints to cntext of sh:or/and/not
<ericP> PROPOSED: amend property constraint take logical operations sh:and, sh:or, sh:not
<simonstey> +1
<hknublau> +1
<Dimitris> also inverse
+1
<jamsden> +1
<Labra> +0.5
<ericP> +1
<Dimitris> +1
RESOLUTION: amend property constraint and inverse property constraint to take logical operations sh:and, sh:or, sh:not
<trackbot> issue-134 -- does SHACL syntax distinguish inverse property constraints -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/134
ericP: difference between prop and invProp is an issue... from Peter
hknublau: dimitris proposed a solution that would simplify this
... you don't know what kind of constraint you are getting
<Dimitris> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016May/0080.html
ericP: one issue being able to know if constraint is inverse or not? cannot have flag that is boolean - inverse T/F?
hknublau: with boolean you can have multiple values; will need a type arc? all constraint types are disjoint
ericP: all require something in the graph that doesn't have a default - ?
hknublau: if you put nothing, then it's like rdfs:range, and it infers a default type
... property defines constraint type sh:property, sh:inverseProperty
... separate sparql constraint form node constraint; then sh:constraint is separate - may be renamed in future
simonstey: a good idea; not strong about splitting off sparql cnstraints
... might help when we hae a different execution language (not sparql)
... do we want to name it 'sparql constraint" or a more generic "execution language constraint"?
<ericP> <S> sh:sparqlConstraint [ ... ] vs. <S> sh:scriptConstraint [ sh:lang sh:SPARQL ]
<Dimitris> or sh:native ?
<ericP> nice
Dimitris: no problem with naming
hknublau: generalizing has a benefit, but not sure if it's a strong argument; it's the split that matters
<Dimitris> STRAWPOLL: adjust sh:constraint and make it link only to sh:NodeConstraints, SPARQL constraints will be linked with another propoerty e.g. sh:sparqlConstraint
<hknublau> +1
<Dimitris> +1
<TallTed> +1
<jamsden> +1
<simonstey> +1
<Labra> +1
<ericP> +1
0
<ericP> trackbot, end meeting