See also: IRC log
<scribe> scribenick: hknublau
<Arnaud> PROPOSED: Approve minutes of the 25 February 2016 Telecon: http://www.w3.org/2016/02/25-shapes-minutes.html
RESOLUTION: Approve minutes of the 25 February 2016 Telecon: http://www.w3.org/2016/02/25-shapes-minutes.html
(Missing Harold from minutes)
<Arnaud> PROPOSED: Open ISSUE-123 DirectType syntax
<simonstey> issue-123
<trackbot> issue-123 -- Shall we unify the syntax of sh:directType and sh:class? -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/123
jamsden: what was the motivation for directType anyway?
hknublau: From Arthur, OSLC
jamsden: I would prefer being consistent with inheritance
... I will talk to Shapes users to see why this is needed.
... Unintended inferencing is a different problem
<Dimitris> +1
<TallTed> +1 open it
+1 open for now
<simonstey> +1
RESOLUTION: Open ISSUE-123 DirectType syntax
Arnaud: I would like to get feedback on the status of a few issues
<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: Differences between ShEx and SHACL - properties can be disjoint by default
... we are trying to come up with an approach that works for all
... iovka may join later
<trackbot> ISSUE-68 -- pre-binding not defined in SHACL spec -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/68
<kcoyle> (as I predicted, app dropped me; back on computer)
+q
<simonstey> is this about the $varname stuff?
hknublau: The proposals page is not yet up to date. The spec has a new paragraph.
... my preference would be to expose this to implementers
http://w3c.github.io/data-shapes/shacl/#pre-binding
<jamsden> It would be nice to see an example
hknublau: will send an update email, please look
<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
<simonstey> +q
<Arnaud> https://www.w3.org/2015/12/17-shapes-minutes.html#item06
ericP: ShEx has a notion of URI stems
... for value matching, only gets us halfway
simonstey: Dereferencing is mentioned in Use Cases document
... people agreed this is out of scope for SHACL
kcoyle: Regex matching is similar to stemming, but stemming is very common in our use cases.
ericP: ShEx stemming construct is for convenience only.
<kcoyle> agreed
<kcoyle> We would definitely use the simpler interface
ericP: Do people support this (slightly redundant) stemming feature?
<Arnaud> ACTION: ericP to send proposal for sh:Stem in response to ISSUE-80 [recorded in http://www.w3.org/2016/03/03-shapes-minutes.html#action01]
<trackbot> Created ACTION-36 - Send proposal for sh:stem in response to issue-80 [on Eric Prud'hommeaux - due 2016-03-10].
Arnaud: Some tickets were never talked about.
<trackbot> issue-52 -- Define an Abstract Syntax for SHACL -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/52
Arnaud: Since Arthur left, would anyone want to continue?
ericP: ShEx Abstract Syntax could be harvested, I could work out something
jamsden: Abstract Syntax is a good idea, but if there is only one Concrete Syntax then what is the point
... also SHACL is tied to RDF, so this feels like a nice to have only, should not delay the process
Arnaud: maybe there is value for documentation purposes, as a side project
... we are not ready to kill this off yet, let's wait for Eric's proposal
<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> https://www.w3.org/2016/02/25-shapes-minutes.html#item06
hknublau: Updated proposals are on the wiki page, would be nice to see more feedback
<Dimitris> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-99.5:_handling_lists_and_resources
<Arnaud> PROPOSED: No special cases for sh:class and friends. This means that Turtle lists don't validate against sh:class rdf:List and that many nodes don't validate against rdfs:Resource
<Dimitris> +1
+0.5
<TallTed> +0
<Labra> 0
<kcoyle> 0 (kinda what the hell)
<jamsden> +0
<hsolbrig> 0
<simonstey> 0
<ericP> 0 (kinda what the hell)
<simonstey> what are those "many nodes"?
hsolbrig: I am confused about Turtle lists. Why should they be different than any other list
hknublau: It's about that lists written in Turtle don't produce an rdf:type triple.
TallTed: We could solve this by adding a Shape and use sh:valueShape
Dimitris: I suggest using NodeKind
<Arnaud> PROPOSED: No special treaments of rdf:List and rdf:Resource at sh:class. This means that Turtle lists don't validate against sh:class rdf:List and that many nodes don't validate against rdfs:Resource.
<kcoyle> +.5
<simonstey> +0.9
0.5
<Labra> +0.5
<Dimitris> +1
<hsolbrig> 0.5
<TallTed> +0.5
<ericP> 0 (kinda what the hell)
<jamsden> +0.5
<ericP> +1 -kinda what the hell
RESOLUTION: No special treaments of rdf:List and rdf:Resource at sh:class. This means that Turtle lists don't validate against sh:class rdf:List and that many nodes don't validate against rdfs:Resource.
TallTed: This WG is best suitable to define a standard Shape for well-formed rdf:Lists
<simonstey> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Feb/0045.html
<simonstey> +q
simonstey: Special construct was asked for by various use cases. I would prefer to have such a feature. But we left this to future work.
<simonstey> issue-119
<trackbot> issue-119 -- Defining constraints on (values of) rdf:Lists -- closed
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/119
hknublau: We could leave this to a general rdf:List library that can be created by 3rd parties
kcoyle: Many people hate rdf:Lists, but it's basic RDF standard, so we need to do something about it.
hknublau: if we are to add a standard Shape, someone needs to produce a draft
... We should however add three NodeKinds, esp for BlankNodeOrIRI
<Arnaud> PROPOSED: sh:NodeKind should be extended with sh:BlankNodeOrIRI (and the two other combinations)
+1
<jamsden> These aren't well enouth specified for me to adequately assess them
<Dimitris> +1 but indeed we should enumerate all options
<simonstey> +-0
hknublau: The three new terms could be sh:BlankNodeOrIRI, sh:BlankNodeOrLiteral, sh:IRIorLiteral
<Arnaud> http://w3c.github.io/data-shapes/shacl/#AbstractNodeKindPropertyConstraint
<Dimitris> i would suggest to add only sh:NonLiteral + the old ones (sh:IRI, sh;BlankNode, sh:Literal)
@Dimitris, I have seen use cases for sh:NonBlankNode (aka IRIOrLiteral).
<Dimitris> we can use sh:or for special cases I think but I don;t mind to add more if needed
<kcoyle> can they not be combined as individuals?
<Dimitris> sh:IRI, sh;BlankNode, sh:Literal, sh:NonIRI, sh;NonBlankNode, sh:NonLiteral ?
<simonstey> sh:not ?
<simonstey> +1 to Karen's concerns
<Arnaud> PROPOSED: sh:NodeKind should be extended with sh:BlankNodeOrIRI, sh:BlankNodeOrLiteral, sh:IRIorLiteral
<ericP> and any node would be blurlteral?
<hsolbrig> +1
<ericP> +1
<kcoyle> +1
+1 (But Dimitr's syntax would be fine too)
<Dimitris> +1
<jamsden> I don't undestand how this would be used to constrain the list, so can't vote intelligently
<iovka_> +1
<Labra> +0.5 (I would prefer NonLiteral)
<simonstey> sh:not [ sh:property [ sh:predicate ex:prop; sh:nodekind sh:Literal ] ]
<TallTed> +0.5
<simonstey> +0.5
<TallTed> I like Dimitris alternative sugar, too
RESOLUTION: sh:NodeKind should be extended with sh:BlankNodeOrIRI, sh:BlankNodeOrLiteral, sh:IRIorLiteral
<Arnaud> PROPOSED: change possible values of sh:NodeKind to sh:IRI, sh;BlankNode, sh:Literal, sh:NonIRI, sh;NonBlankNode, sh:NonLiteral
+0
<Arnaud> PROPOSED: change possible values of sh:NodeKind to sh:IRI, sh:BlankNode, sh:Literal, sh:NonIRI, sh:NonBlankNode, sh:NonLiteral
<hsolbrig> +0
<Dimitris> +1
<simonstey> +0,5
<kcoyle> -.5
<TallTed> +0.5 (shorter strings, same meaning, I think will fit thinking more often)
<Labra> +0.8
<ericP> +1
kcoyle: Not would be better than Non.
<TallTed> Non is perfectly valid English usage...
<ericP> +1 to naan
<TallTed> BlankNode should all become Blanknode -- everywhere
<Dimitris> NonBlanknode with lower n
<kcoyle> -1
<TallTed> TallTed: inappropriate camelcasing on Blanknode should be undone. `BlankNode` should all become `Blanknode`.
<Arnaud> trackbot, end meeting