See also: IRC log
<scribe> scribe: simonstey
<Arnaud> PROPOSED: Approve minutes of the 10 March 2016 Telecon: http://www.w3.org/2016/03/10-shapes-minutes.html
<pfps> minutes look OK
RESOLUTION: Approve minutes of the 10 March 2016 Telecon: http://www.w3.org/2016/03/10-shapes-minutes.html
<Arnaud> PROPOSED: Open ISSUE-134 knowing inverse, ISSUE-135 and/or syntactic sugar, ISSUE-136 Property pair names, ISSUE-137 language tag
<hknublau> +1
+1
<kcoyle> +1
<Dimitris> +1
<hsolbrig> +1
<ericP> +1
RESOLUTION: Open ISSUE-134 knowing inverse, ISSUE-135 and/or syntactic sugar, ISSUE-136 Property pair names, ISSUE-137 language tag
issue-80
<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
Arnaud: we talked about it last week; eric sent out an email about how stem works in shex.. where do we stand now?
ericP: was I about to send a proposal on how this would look like in shacl?
Arnaud: thought this would be a low hanging fruit
issue-129
<trackbot> issue-129 -- Existential constraints should be consistent -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/129
Arnaud: dimitris raised that issue
... we should spend little bit of time discussing it; some votes were already cast
Dimitris: the definition of extential constraints might not be the best one
... but e.g. hasValue works different from other constraint types in shacl
... while others only work over exisiting values, this does not
pfps: holger had a perfect description for that
... i see no possibility of changing the meaning of hasValue since it works exactly as it should
Arnaud: so you are saying there is nothing to be fixed?
pfps: no.. espec. the meaning of the newer ones need some fiddling
... the problem doesn't go away if you get rid of the existential ones
... e.g., equals, minCount have a clear meaning and people would scream at us if we change it
ericP: i'm wondering whether people actually understand the implications of what you are saying?
pfps: when people do db querying, they get confused if they get no answers for a query
Arnaud: example: there must not be a property with a certain value less than x
... does the value need to exist?
Dimitris: this is not an implementation issue; that's the easy part
... I was worried about users actually understanding the meaning of hasValue
... it could e.g., be changed to sh:requiredValue
<pfps> The definition for hasValue is "The property sh:hasValue can be used to verify that the focus node has a given RDF node among the values of the given predicate. " This seems to be very obvious.
jamsden: what's the confusion here?
<pfps> For sh:in "The property sh:in exclusively enumerates the values that a property may have. When specified, each value of the given property must be a member of the specified list. "
<pfps> Both seem quite obvious and the right definition
pfps: there is no such thing as undefined in SPARQL
... it's there or not
... the current definitions seem pretty obvious to me
jamsden: same for me
<Dimitris> Jim, the problem is that sh:in ("foo") and sh:hasValue "foo" behave differently
<pfps> In RDF values are not associated with properties.
kcoyle: the cardinality constraints are on the property and not the value, right?
<hsolbrig> how about "includesValue"
pfps: in shacl, everytime you are doing something you have a property in hand
<hsolbrig> "has" tends to be fuzzy whether we're dealing with a set or an individual
<hsolbrig> or, to be more orthogonal with "in", just "includes"
<ericP> { [ sh:predicate :foo; sh:hasValue 1; sh:hasValue 2 ] } \ { <s> :foo 1,2,3 }
<hsolbrig> +q
<ericP> { [ sh:predicate :foo; sh:in ( 1 2 ) ] } \ { <s> :foo 1,2,3 } => fail
pfps: e.g. sh:in looks at each of the values separately (for each of those values..)
<ericP> +1 to harold's proposal
<ericP> though i'm curious about use cases for this
pfps: minCount on the other hand works over the whole set of properties
<ericP> maybe ditch sh:hasValue ?
pfps: two triples that have the same S, P but different Os resemble something like multivalued properties
<hknublau> hasValue is very common in filters
<kcoyle> I think hasValue has lots of uses -- unless I misunderstand it
<pfps> I agree with Holger that hasValue would be very common in filters
hsolbrig: the confusion comes from the fact that its meaning can be understood as "its value includes"
... or "its value is"
<ericP> hknublau, can you describe how hasValue is used in filters?
<hknublau> "Every person who has bornIn = USA must not travel to Cuba"
Arnaud: so how do we make progress here?
pfps: whoops.. my proposal is simple -> do nothing
Arnaud: lets give it another week, there is no rush on closing now
Arnaud: there was extensive discussion on that on the mailing list
issue-65
<trackbot> issue-65 -- Consistency and cohesiveness of nomenclature (e.g., shapes, scopes, and constraints) -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/65
issue-120
<trackbot> issue-120 -- The spec must be more precise and consistent about when a resource is a shape, a class, and an instance of a class -- closed
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/120
scribe: those issues might be related to that topic
pfps: I'm pretty sure that SPARQL isn't using "instance" anywhere in its spec
<Dimitris> \
hknublau: we certainly need to improve the wording
<ericP> pfps, SPARQL 1.1 uses instance for the notion of "instance mapping"
<ericP> (and a few instances of "for instance")
hknublau: we have some redudancies in the document that where meant to support understanding but might ended up confusing people
<pfps> the overhead will be about 100 words in a long document
hknublau: I do not agree with pfps that we are violating any ???
Arnaud: we need to make sure that the spec isn't wrong
... for me the downside of pfps' proposal is that it might be a bit painful of having to write "SHACL instance" everytime
... but at the same time I'm sensitive to his proposal
... since people might not read the document from the beginning to the end
pfps: I think we need to be crystal clear about the difference between SHACL instance and RDF(S) instance
Dimitris: we could try to remove all uses of instance, but we've to see
pfps: I found a hole in the metamodel.. which is kind of disturbing
... when a property is both a target of a inversepropertyconstraint as well as a propertyconstraint, it behaves strange
[... pfps writing down an example ...]
<pfps> sh:shape sh:property [ a sh:InversePropertyConstraint ; sh:predicate ex:foo ; sh:minCount 2 ]
[ericP & pfps discussing the example]
<ericP> validating <X> as the above:
hknublau: it's unfinished but not broken
... both of your examples are invalid shape graphs
<pfps> sh:shape sh:property [ a sh:PropertyConstraint ;a sh:InversePropertyConstraint ; sh:predicate ex:foo ; sh:minCount 2 ]
<ericP> <Y> :foo <X>. <Z> :foo <X>. <X> :foo <Y>. <X> :foo <Z> .
hknublau: what we could do is, making propertyconstraint and inversepropconstraint disjoint
... so a constraint can't be both at the same time
<ericP> <Y> :foo <X>. <Z> :foo <X>. <X> :foo <W>. <X> :foo <K> .
ericP: in shex we just have a flag that says whether something is forwards or backwards
pfps: people can do a lot of silly, stupid and/or smart things in RDF
... you don't want to have to deal with defending your syntax against stupid/silly/.. proposals just because you weren't explicit enough in specifying what's allowed and what's not
Arnaud: I want people to investigate pfps proposal
<ericP> pfps, did OWL address this by saying that a parsing OWL from RDF fails if there is more than one way to parse it?
Arnaud: I think pfps has made a fair amount of effort in providing information about his proposal
<pfps> OWL solves this problem by making string requirements on graphs that are valid OWL ontologies
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/ISSUE-95:_Metamodel_simplifications#Proposal_4
<pfps> I believe that Holdger said that syntax with positional arguments was an anti-pattern
Arnaud: I want to step back from discussing specific issues and discuss pfps proposal
ericP: maybe pfps wants to give us a short description of his proposal now?
<ericP> https://www.w3.org/2014/data-shapes/wiki/ISSUE-95:_Metamodel_simplifications#Proposal_4
pfps: 1) sh:property/invprop. you have to pull out the property and put it in a list; the benefit is that you don't have to worry about not knowing in which direction you have to go
... 2) sh:pattern is a little bit odd right now
<ericP> current: ex:MyShape a sh:Shape ; sh:constraint [ a sh:Shape ; sh:predicate ex:myProperty ; sh:class ex:Person ; sh:in ( ex:Susan ex:Bill ) ] .
<ericP> pfps: ex:MyShape a sh:Shape ; sh:fillers ( ex:myProperty [ a sh:Shape ; sh:class ex:Person ; sh:in ( ex:Susan ex:Bill ) ] ) .
<ericP> current: ex:MyShape a sh:Shape ; sh:property [ a sh:Shape ; sh:predicate ex:myProperty ; sh:class ex:Person ; sh:in ( ex:Susan ex:Bill ) ] .
<ericP> pfps: ex:MyShape a sh:Shape ; sh:propValue ( ex:myProperty [ a sh:Shape ; sh:class ex:Person ; sh:in ( ex:Susan ex:Bill ) ] ) .
pfps: you can't have two properties inside the square brackets to combine together
... currently it's painful to repeat things
... 3) you can actually put e.g. sh:minCount anywhere in the shape
<ericP> ex:PersonShape sh:minCount 1e10 .
pfps: there are no more node/property/invpropertyconstraints anymore
... there are only shapes; very similar to shex
Arnaud: I'm wondering whether the WG thinks we should spend time on looking into this or not
<Arnaud> STRAWPOLL: continue investigating Peter's proposal there may be something there (+1: agree, 0: not sure, -1: disagree)
<ericP> +1
<hsolbrig> +1
+1
<hknublau> -1
<Labra> +1
<kcoyle> +1
<pfps> +1 (surprise!)
<Dimitris> 0- ( I think there are good elements but not user friendly)
<jamsden> +0
but we might adopt some bits and pieces
<pfps> I note that I have updated my previous SHACL implementation for this new syntax. It is about 80% complete.
<jamsden> I don't see the motivation for such a significant change at this late date
<pfps> to be fair, RDF makes for complex, long, and hard-to-understand syntax
<jamsden> these issues just aren't that compelling to me
<jamsden> what is the process for assessing, evaluating and deciding on a resolution?
Arnaud: I encourage everybody to have a read on pfps proposal
iovka's email: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0219.html
document: https://hal.archives-ouvertes.fr/hal-01288285/document
iovka: I'm a formal methods person; so in order to understand SHACL I generated an abstraction of SHACL
... I used presburger arithmetics for capturing shex (not needed for shacl)
... future goal is to come up with a transformation between shex <-> shacl
... I would need some support from someone who's more familiar with shacl than me for checking whether I captured shacl correctly or not
Arnaud: I'm quite grateful on what iovka is doing
pfps: the reason why I jumped on hasValue is that I'm not sure whether the current formalism is actually capable of capturing it (haven't looked at it though)
iovka: I had a brief look at it today and it appears to be one of the easiest constraints
<ericP> iovka expressed [] sh:hasValue 1 as ShEx as <S> EXTRA :foo { :foo [1] }
<pfps> my time is likely to be very limited for a while starting very soon now
I will have a read
<Arnaud> trackbot, end meeting
<iovka> quit