See also: IRC log
<Dimitris> I can scribe
<Dimitris> scribe: dimitris
arnaud: let's talk about the UI-related issues
... shacl annotations to drive user interfaces
... peter said UI is a complex matter and we cannot do the full job
... before we look at specific issues we should do a high level talk
... strip all UI annotations or add at least some annotations
arthur: shacl should enable UI, at a high level that a form builder can display fields and perform validation
<pfps> Even the simple stuff currently in SHACL or being proposed should have two interoperating implementations for it to be acceptable to W3C.
arthur: we need to enable UI features
Kcoyle: we should call it UI, form building is more approapriate
... agree with arthur, UI is complex
hknublau: it is part of our mission to enable form building, also part of the charter
... giving up should be under strong reasons
... index and property groups are simple enough to include and I will not suggest other features
... shacl already includes a lot of features (e.g. datatypes) that can drive form building
... groups and index are very common and easy to include
arnaud: the charter does not tell us how far we go
pfps: there is some stuff in shacl, quite useful for forms
... we can stop here, that doesn't get us in the difficult decision on how far we go
... like liner / tree interfaces
... UI needs implementation e.g. sh:defaultValue
arnaud: not sure how much implementation proof we need
pfps: we need proof of usage
arnaud: right, we don't need a test suite but at least some proof
... who would implement these features?
kcoyle: we have different workflows
... the same data will be used in different context and UI is one context
simonstey: I have a different opinion, some features can only be used in UI-stuff e.g. defaultValue
... in Siemens we have use cases and e.g. sh:defaultValue is needed
<pfps> if sh:defaultValue has a different use, then that different use could be the defining one, so long as there was an implementation. however, my view is that W3C process requires some sort of interoperable implementation for each feature of SHACL
simonstey: we can not focus on UI stuff but we can enable ordering
arnaud: defaultValue does not strike as solely UI but others do
hknublau: in respond to Karen, shapes are the perfect match. we need a minimal framework
<pfps> I don't see how scopes can be used to differentiate between different UI setups on the same shape
hknublau: my previous approach was to focus on the templates while the WG needs more things in the core language
... testing is indeed hard, we can write some appendix on how to use that
<simonstey> implementations in the sense of applications using shacl or actual shacl engines?
arnaud: we need to show we have implementations from the W3C process
... we don't need a test suite but we need a least two people who claim they implement it
pfps: if we add sh:index and put together a use case none believes in it is a bad idea
... if we put things in shacl we should do it only if we believe people will use it
pfps, can you scribe you last comment?
<Arnaud> STRAWPOLL: a) drop off UI related features, b) support some UI related features
<hknublau> a) -1 b) +1
<simonstey> a) -1 b) +1
a) -0.5, b) +1
<pfps> the rationale for changing the SHACL spec document with respect to the SHACL core has no commonallity with not having UI features in SHACL
<pfps> a) -1, b) +1
<aryman> irc dropped me - please reenter the proposal
<pfps> I agree with Karen but I think that the thrust of the straw poll is correct
<pfps> oops
kcoyle: it's not black & white, some parts are also documentation
<pfps> a) +1, b) -1
<hknublau> @pfps I think we are talking about different things.
<ericP> i'm completely undecided
kcoyle: some parts of shacl can be be only UI and some both
<ericP> a) ?, b) ?
<simonstey> that was my point
<simonstey> +q
<hknublau> To me it already looks like we cannot make a general decision.
<aryman> please repeat the straw poll question
<kcoyle> STRAWPOLL: a) drop off UI related features, b) support some UI related features
kcoyle: we need to define our terms, what do we mean by UI-related
simonstey: we can drop external UI-related requests
<simonstey> maybe https://www.w3.org/2014/data-shapes/track/issues/114
arnaud: can you give me an example of a feature that can be used both for UI ?
hknublau: sh:index can also be used to write turtle files and preserve the order
<aryman> a) -0.5 b) +0.5
arnaud: are we limiting ourself to validation only?
<pfps> sh:description is a SHACL property that could be used for UIs. In fact, its main purpose is UI-related. However, sh:description is hooked into SHACL error reporting, which, I think, was its initial purpose. That said, there is still a need for implementation experience related to sh:description.
kcoyle: if parts of shacl can be used for UI that's fine
<kcoyle> a) + .5 b) -.5
arnaud: strawpoll indicates people are interested in UI, we will look in a case by case basis
<trackbot> issue-100 -- Specifying the order of property constraints (e.g. with sh:index) -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/100
<hknublau> (sh:index should be renamed to sh:order)
<aryman> maybe sh:sortKey
hknublau: harold suggested sh:order, index starts from 0 order is more flexible
<aryman> allows xsd:decimal values
<hsolbrig> plus, index could be perceived as an identifier. Confusing...
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-100:_sh:index
<hknublau> PROPOSED: Add an optional annotation property sh:order (datatype: xsd:decimal) to property constraints, with the intention of representing the relative ordering of properties, e.g. for display purposes.
pfps: what optional means here?
... this proposal comes out of the blue, it's different from issue 100
... issue 100 specifies the order of property constraints, this proposal talks about properties
<Arnaud> PROPOSED: Add an annotation property sh:order (datatype: xsd:decimal) to property constraints, to represent the relative ordering of properties in the context of a shape, e.g. for display purposes.
<simonstey> the order in which property constraints shall be evaluated?
<Arnaud> PROPOSED: Add an annotation property sh:order (datatype: xsd:decimal) to property constraints, to represent the relative ordering of property constraints, e.g. for display purposes.
<Arnaud> PROPOSED: Add an annotation property sh:order (datatype: xsd:decimal) to property constraints, to represent the relative ordering of property constraints, for uses such as form building
<hknublau> +1
ericP: in shex everything is ordered and we don't anything special
arnuad: if you need to translate shex in shacl would you need this feature?
hsolbrig: yes
ericp: if shacl doesn't have order, we would need a way to translate shex into shacl
<pfps> 0 but note that for this feature to survive there needs to be an implementation that uses it for a useful purpose
<hsolbrig> +1
<ericP> +1
+1
<simonstey> +1
<aryman> +1
<kcoyle> +.5
kcoyle: is annotation the same as owl annotation property?
https://www.w3.org/2014/data-shapes/wiki/Requirements#Annotations
hknublau: similar but not the same
<simonstey> but for the ShEx use, it should affect the validation right?
aryman: this also applies to inverse property constraints
... the wording of the original proposal was correct
... we can have multiple property constraints for the same property
RESOLUTION: Close ISSUE-100, add a property sh:order (datatype: xsd:decimal) to property constraints (and inverse ones), to represent the relative ordering of property constraints, for uses such as form building
<hknublau> Looks good to me.
<kcoyle> yes
<hsolbrig> yes
yes
<ericP> yes
<trackbot> ISSUE-113 -- Let a user interface group design the connection between SHACL and UI tools -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/113
arnaud: should we close this?
<Arnaud> PROPOSED: Close ISSUE-113, with no action
pfps: the WG can close this with no action
<pfps> 0
RESOLUTION: Close ISSUE-113, with no action
<trackbot> ISSUE-114 -- Should SHACL include a grouping mechanism of properties (for UI purposes) -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/114
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-114:_Property_Groups
hknublau: in forms we can create groups of properties e.g. address-related fields
... the properties will be ordered and the groups can also be ordered
... this is a common pattern we have in practice
<Arnaud> PROPOSED: Close ISSUE-114, adding property groups as proposed
<hknublau> +1
<hsolbrig> +1
<simonstey> +0.5
+0.5
<kcoyle> -.2
<pfps> 0 noting that this feature will need UI usage to survive
<aryman> +0.5
<ericP> +1
<pfps> karen?
<kcoyle> yeah?
<pfps> i'm surprised at your vote
kcoyle: I feel this is heading down in adding things only intended for UI
<hknublau> To me this is the last of this kind for the foreseeable future.
for ordering turtle documents again?
<simonstey> we just talked about that but didn't vote
aryman: this can be used for documentation
hsolbrig: this is useful for grouping
RESOLUTION: Close ISSUE-114, adding property groups as proposed
<pfps> the implementation experience is going to need two implementations for the same purpose, otherwise there is no interoperability
arnaud: if there is no implementation at the end we will drop them
... 15 minutes break
<hsolbrig> test
<aryman> Scribe: aryman
<hknublau> This was already discussed yesterday. We can skip this today.
<Arnaud> PROPOSED: Close ISSUE-23, don't have sh:ShapeClass, require explicit scopeClass
Arnaud: yesterday the WG voted to not infer sh:scopeClass in the absence of Holger
<hknublau> -1
+1
<ericP> +1
<pfps> +1
<hsolbrig> +1
<kcoyle> +1
<simonstey> +0.5
<Dimitris> +1
<pfps> any comments from Holger?
<scribe> chair: Arnaud
Arnaud: asks Holger why the -1? what does it take to change your vote?
hknublau: disappointed that the topic was discussed in my absence. doesn't know what was discussed so can't really react
Arnaud: asks why is it a problem that sh:scopeClass be present explicitly
hknublau: this is a major usability issue. It will impair the adoption of SHACL.
... the semantic web needs a modelling language like SHACL. OWL is not suitable and has not been adopted much. Too academic. Requiring three triples looks bad.
... suggest adding rules to SHACL, as in SPIN, that add additional triples
... similar to OWL-RL. Use SPARQL CONSTRUCT queries.
Arnaud: what's the connection between sh:scopeClass and Rules?
the rule add missing triples like sh:scopeClass
ericP: which of your users would object since they use TopBraid and the form based interface to create shapes?
hknublau: I believe the main growth area is JSON users. SHACL could become a better schema language for JSON, better than JSON-schema
pfps: would adding rules to SHACL require a re-chartering?
Arnaud: it sounds like Holger is just looking for reaction of the WG at this point
<simonstey> I would like to see rules in SHACL ;)
Arnaud: the clear majority of the WG voted to not infer sh:scopeClass
hknublau: can we discuss my proposal for rules?
Arnaud: first let's resolve ISSUE-23
pfps: against expanding the charter of this WG, not the right people here
simonstey: I am in favour of rules since they are very useful in many cases
<Dimitris> I agree with Simon
<pfps> do the minutes reflect whether simon and dimitris agree with taking up rules in the wg?
hknublau: inferring the triples seems very low hanging - what is the objection
Dimitris: rules would be useful, but it does look out of scope
Arnaud: asks pfps why he feels inferencing would be difficult
pfps: the main point of difference is the role of SHACL as a modelling language. Holger believes SHACL should be a modelling, I believe it should not since there are other W3C modelling languages and we should build on those
hknublau: so there is really no technical obstacle to inferring sh:scopeClass - this is purely a philosophical argument about the role of SHACL.
<Zakim> ericP, you wanted to say that it's one extra triple at the minimum, 2 extra at the max, needlessly obscures scopeClass, and encourages short-sighted modeling with non-reusable
hknublau: OWL has not succeeded in the marketplace.
ericP: inferring sh:scopeClass would make it difficult for people to understand the scope since it requires inferencing and is not explicit
<pfps> holger had a very nice argument, but that argument needs to be made to W3C, not to this working group
Dimitris: preferred option (d) which eliminated RDFS inferencing
Arnaud: has been championing Holgers proposal but it didn't fly
aryman: both camps are raising spurious objections to this ISSUE-23. The real issue is the status of SHACL as a modelling language. Let's resolve this issue.
Arnaud: If TQ implements inferencing then they can gauge the market acceptance and influence SHACL.
Dimitris: SKOS was not intended as a modelling language but is used this way now.
<pfps> there are many things that the working group has done that I am strongly against - that's how things go in a working group
hknublau: TQ did concede on the decision to separate Shapes and Classes even though we believed it was wrong. I am disappointed in the process.
<Arnaud> PROPOSED: Close ISSUE-23, don't have sh:ShapeClass, do not require explicit scopeClass
Dimitris: This requires the ontologies to always be available.
<pfps> -1 assuming that this means roughly do what is in the editors' draft right now
<hknublau> +1
Dimitris: still need to do inferencing e.g. on rdfs:subClassOf
<kcoyle> ?? not a clue
+0
<hknublau> For the record I could also live with Dimitris approach.
<Dimitris> -0.9
<simonstey> 0 not sure about the implications
<hsolbrig> +0
Arnaud: asks Dimitris to rephrase proposal using option (d)
<Arnaud> break 30mn
<hsolbrig> I have to step out in half an hour
<Arnaud> ok, so maybe we'll just postpone that to tomorrow
<Dimitris> PROPOSED: Close ISSUE-23 by introducing sh:ClassShape, a rdfs:subClassOf sh:Shape. sh:ClassShape indicates that the Shape IRI is also the sh:scopeClass of the Shape and forbids an explicit sh:scopeClass declaration. If and where the shape IRI is defined as an rdfs:Class is out of scope for SHACL.
<Arnaud> do you really mean "forbids"?
<Arnaud> I think that's stronger than you mean
<Arnaud> what if I still had scopeClass? wouldn't necessarily be a problem, right?
<Dimitris> this would lead to confusion on which scope is used (if different)
<Dimitris> but we can discuss that
<pfps> i can scribe
<pfps> scribe: pfps
Arnaud: is there is a chance for a real F2F?
My travel budget for 2016 is still unknown, but likely to be small
Arnaud: It would be nice to get a few options and then maybe do a poll
... MIT may be the best option
... we need critical mass at the actual meeting
Holger: I think that the format for this meeting is good, particularly the six hours and short breaks
Arnaud: Short lunch breaks make it difficult to go out for lunch
... should we try to have a F2F meeting?
Eric: I don't think I will have funds to travel
Dimitris: US will be hard for me
Arnaud: should we just go for virtual
pfps: I have a slight preference for a physical F2F, but only if nearly everybody shows up
Arnaud: I also prefer a physical F2F, but with few people there, then no
... the F2F in France had attendance but even not everyone in Europe was there
... what dates work?
... three months from now is March
pfps: mid to late march works well for me
<Dimitris> I will be unavailable from 26/2 - 5/3
Arnaud: W3C AC meeting is 20-22 March
... three months from now is 15-17 March
pfps: we probably should have an alternate time
Arnaud: March 8-10 or 29-31 are options
Araud: also physical at MIT 23-25
Arnaud: I'll set up a doodle poll
eric: I have a meeting in San Francisco March 21-24
Arnaud: I'll drop that option off the poll
Arnaud: recursion is one of the big issues
... one extreme is to disallow recursion
... people find recursion useful, but full-fledged recursion has problems
... can we find a sweet spot that does not have problems
... there are specific issues that are open as well
arthur: there is a wiki page with use cases for ISSUE-66
arthur: so there is interest in recursion
... we don't really have a good spec for recursion
... there is nothing in the spec that defines how recursion works
... we could take a conservative position and reject any shapes graph that where a shape refers to itself
... this gives us a starting point that will work
... I have a document that specifies how to interpret positive recursion - no negation, no disjunction
... if you limit yourself to that subset there is no semantic problem but this needs to be turned into suitable stuff for the SHACL spec
... you could go further and look at recursion with negation and disjunction
... a definition of recursion with negation came from Iovka, I think that it had no problems
... however that approach is not being maintained
... perhaps the most recent ShEx spec has a good definition of limited recursion but I'm not motivated to look at a ShEx version of recursion again
... I'm not sure how much further than the positive case we can go
arnaud: it seems like negation always comes up and maybe we can agree not to include this
arthur: with recursion over negation you can easily get inconsistent shapes
holger: I generally agree that we can go for the simple solution and support recursion for only the simple cases
... this should cover most of the useful cases and not be hard to implement
pfps: I'm not sure that arthur and holger are saying the same thing
... I think that arthur's base case is no self-reference
arthur: the starting position should be no self-reference in shapes
... I believe that it is possible to have a clean spec for positive recursion
... positive recursion can be included when a solution is found
... further expansions could also be possible
pfps: the diference I see is recursion vs data loops
... arthur wants to be conservative on recursion
... the current spec is conservative on data loops
... that's a big difference
arthur: correct
... the reason is that we don't say what happens when we hit a data loop and that causes circularity
... if you allow recursion then you have to say what happens on data loops
... this is complicated and not specified well in the current spec
arnaud: is there any disgreement on this?
arthur: I propose that if there are any dependency loops in the shape graph then it is invalid
<Zakim> ericP, you wanted to ask about working with Iovka on recursion
eric: it seems like the people who have done the most work on recursion ...
... ... ShEx allows shapes recursion but only in limited circumstances
... recursion is allowed and loops are defined as success
... why can that not be the base case?
arthur: that is unintuitive
... that doesn't give you a procedure for computing the typings
scribe note: I may have messed up the ShEx situation - ShEx is more like "guess an assignment and then verify that it works"
arthur: I'm not motivated to look at yet another ShEx paper unless it is tied to SHACL somehow
eric: what kind of contribution would you like
arthur: how about a spec (for recursion) that used the terms of SHACL/
eric: OK
arnaud: there is time for SHACL vs ShEx later so let's leave that aside for now
arthur: I'm proposing that the spec should be well grounded and only include what is known to work completely
arnaud: that is a pragmatic approach
... arthur is saying that we should simplify the problem for now
... without prohibiting expansions
... is that reasonable?
<Dimitris> +1
this works for me
arthur: a shacl graph with a loop would be invalid and throw an error
... before any validation
... a shape can depend on another shape - that defines a relation between shapes
... the prohibition would be against loops in the transitive closure of this relation
<Arnaud> PROPOSED: shapes graphs with loops are invalid
arthur: a SHACL processor would have to check for loops in the dependency relation
arnaud: this proposal could be revisited if further information comes to light
pfps: I think that this proposal is a bit harsh on recursion
PROPOSED: the starting point for recursion in SHACL is that shapes graphs with dependency loops are invalid, suitable limitations of this will be explored
arthur: that is the intention
<hknublau> 0
<aryman> +1
+1
<ericP> 0
<Dimitris> +1
RESOLUTION: The starting point for recursion in SHACL is that shapes graphs with dependency loops are invalid, suitable limitations of this will be explored
pfps: from the point of the working group all this says is that there should be a clean version of the spec for recursion
... the spec should say that recursion remains open
<aryman> +1
arnaud: as long as we don't close the door it is useful to have limited solutions
... what else is there to do?
pfps: I think that someone should push on recursion, or maybe several someones
... there are a number of proposals for recursion on the table
arnaud: with that resolution is there anything else that needs to be fixed in the spec
arthur: if we make that change then the spec is OK
arnaud: so we can live with that for now until there is a workable proposal for recursion
arthur: I think that the spec is in good shape if recursion is removed for now
arnaud: arthur and others will be working on recursion
... can we close issues
pfps: I don't think that we want to close this issue, as there is still work on recursion
arnaud: can we close ISSUE-66
arthur: issue 22 is about static analysis issue 66 is about dynamic analysis
... the current resolution covers both, but if recursion is handled then dynamic analysis is needed
arnaud: we could close 66
pfps: fine by me
PROPOSED: Close ISSUE-66 as being covered (for now) by the previous resolution. Recursion in shapes will need to cover data loops, as indicated in ISSUE-22
+1
<aryman> +1
<ericP> +1
<hknublau> +1
<Dimitris> +1
RESOLUTION: Close ISSUE-66 as being covered (for now) by the previous resolution. Recursion in shapes will need to cover data loops, as indicated in ISSUE-22
arnaud: no other recursion issues
... did we talk about issue-73?
...
... I'm surprised that this went so fast
... maybe it's because we punted
arthur: the spec is complicated so we need to have a firm definition of recursion before proceedings
... in OLSC resource shapes things were simpler so recursion caused fewer problems
... without recursion macro-expansion is a possible implementation technique
... it's conceivable that we could define SHACL-lite that excluded recursion
pfps: the problem with ISSUE-73 is that it is very technical
... I was meaning recursion error, but other errors have same issue
... which is how to errors interact with validation
... do we need a notion of runtime ordering or can we have a spec that is neutral on that
arnaud: we did discuss errors in the context of conjunction
... the spec was ambiguous
holger: I believe that I have a solution that is independent of order, and that depends on three different return values (true, false, and error)
... any place where unbound (error) can arise needs to propagate that error
arthur: we agreed that hasShape is in the spec
<Arnaud> http://w3c.github.io/data-shapes/shacl/#constraints
holger: the spec needs to consider the three return values
arthur: are there any other errors?
holger: unknown execution engines
arthur: in just the core are there any other errors
holger: I don't think so
arthur: just hitting a data loop may not be an error
... what about run time errors like division by zero
holger: division by zero is a different situation
arthur: you shouldn't get exceptions
... the SPARQL spec says what happens
eric: SPARQL does consider these situations
arnaud: i put a pointer to the section of the spec that discusses sh:hasShape
... there is an explanation there
... the question is wether this is sufficient
pfps: it's been a little since I looked at SPARQL, my understanding is that it does do a right thing, we need to also do a right thing
<ericP> sparql -e 'ASK { FILTER (1 / 0) }'
<ericP> false
pfps: my understanding is that SPARQL has problems with silently dropping solutions
arnaud: this looks a bit strange
arthur: SPARQL can do something different as long as it is coherent
eric: SPARQL doesn't try to patch the behaviour of XPATH, which it depends on
arnaud: we need to figure out what to do with the last session today
... can we have a plan on how to close this issue
good enough
ISSUE-76 was closed, specifying that execution order does not matter
this indicates that SHACL should treat errors in such a way that execution order does not matter
of course, there needs to be some fudging about the meaning of "matter"
<hknublau> scribe: hknublau
Arnaud: I think we should continue with ISSUE-73
<pfps> continuing on ISSUE-73 - ISSUE-76 was closed, specifying that execution order does not matter
<pfps> this indicates that SHACL should treat errors in such a way that execution order does not matter
<pfps> we could close this issue, saying that the same idea is to be applied as for ISSUE-76, and leave implementation to the implementators
<pfps> of course, there needs to be some fudging about the meaning of "matter"
pfps: This means that someone needs to go through the spec to make sure that definition order does not matter
... e.g. if there are two errors, who knows which one you get.
<ericP> sparql -e 'ASK { { FILTER (1 / 0) } UNION { FILTER (1 / 0) } }'
<ericP> I'm sorry Dave, I can't do that.
(I think we specced this out already)
ericP: The above produces no solution, errors get masked.
<ericP> sparql -e 'SELECT * { { FILTER (1 / 0) } UNION { BIND (1 AS ?x) } }'
<ericP> +----+
<ericP> | ?x |
<ericP> | 1 |
<ericP> +----+
pfps: I think we can close this until someone shows a problem in the spec.
<Arnaud> PROPOSED: Close ISSUE-73, no need until evidence of an actual problem, addressed with previous resolution of execution order doesn't matter
+1
<aryman_> perhaps we should spell this out as a design principle for SHACL
<pfps> +1
<aryman_> add a statement to the spec
<aryman_> +1
<ericP> 0
<Dimitris> +1
<pfps> I don't think that there is a general statement in the spec to the effect that evaluation order does not matter
I don'tr remember
<pfps> I believe that the spec did change
RESOLUTION: Close ISSUE-73, no need until evidence of an actual problem, addressed with previous resolution of execution order doesn't matter
Arnaud: We could go back to ISSUE-23 now to make sure everyone understands Dimitris' proposal.
<Dimitris> here's the proposal again
<Dimitris> PROPOSED: Close ISSUE-23 by introducing sh:ClassShape, a rdfs:subClassOf sh:Shape. sh:ClassShape indicates that the Shape IRI is also the sh:scopeClass of the Shape and forbids an explicit sh:scopeClass declaration. If and where the shape IRI is defined as an rdfs:Class is out of scope for SHACL.
It should also not have any other sh:scope triple.
<pfps> Isn't this the current situation?
Dimitris: sh:ClassShape is not a metaclass anymore.
... It doesn't automatically make this a class, it just assumes it's a class (declared elsewhere)
Arnaud: An example would help.
<Dimitris> foaf:Person a sh:ClassShape is an example which translates to foaf:Person a sh:Shape; sh:scopeClass foaf:Person
<pfps> I would also like to see some examples of this in use
<Dimitris> the different is that we make no assertions on foaf:Person a rdfs:Class
pfps: This is hard to answer, requires detailed investigation
Arnaud: example in an email for tomorrow would be good
hknublau: This would typically be used in conjunction with a separate RDFS/OWL file that contains the class definitions, without corrupting existing apps
What about the release cycle of the next spec?
It sounds like we made good progress so far
<trackbot> ISSUE-102 -- Missing a way to explicitly code unbound cardinality and open shapes -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/102
Arnaud: We have various places with implicit default values - there are lots of them. If you don't specify anything then there is no constraint.
... we could decide max count is not an integer but an indentifier such as "unbound"
<pfps> no sound
aryman_: While I am sympathetic to Karen, where do we draw the line - we would have to define default values for many other things too
pfps: Current situation is that if there is nothing specified then no constraint is checked.
... one might argue that minCount=0 is useless and should be removed.
<Zakim> ericP, you wanted to ask about defaults
ericP: This works for min/maxCount but has the opposite effect on filterShape
pfps: I would say not.
... filter is an implicit negation
ericP: this may be true but is there value in having this dogma
pfps: We have invisible defaults to do nothing.
... every constraint would have to have an unbounded syntax.
aryman_: sh:minCount=0 actually has some semantics - just to mention the property (open and closed shape)
<pfps> you can have a constraint with no pieces, so it is not the mincount=0 that is the culprit
hknublau: I don't think so. Just stating sh:predicate is enough.
<pfps> in the presence of closed, it is true that just mentioning a property is semantically important, but that is also covered here
<aryman_> @hknublau right - sh:property [ sh:predicate ex:foo]
<pfps> +1 to holger's suggestion
<pfps> actually I would like to see a compact syntax that allows [1,], i.e., doesn't need an explicit max
hknublau: I think this should be handled by other (compact) syntaxes and tools, e.g. [0..*]
Arnaud: I don't think we need to blow this out of proportion - Karen only asked for sh:maxCount. Let's be pragmatic.
<pfps> there are lots of ways of creating vacuous constraints in SHACL, so having mincount=0 isn't special
Dimitris: I agree with the others who are present.
Arnaud: Looks like we cannot make this default for sh:maxCount. What about open shapes?
<pfps> having special syntax that says nothing isn't a great idea, in my opinion
hknublau: With sh:closed as a boolean you already have false
<Arnaud> PROPOSED: leave SHACL as is, but create a maxCount value in the high-level language that is interpreted as the maxCount default in SHACL
+1
<aryman_> +1
<Dimitris> +1
(assuming "high level" means compact syntaxt)
<pfps> why don't I go against mincount=0 then? because mincount=0 just fits into the other mincounts, with no special attention, similarly for empty and and or
<pfps> +1
<ericP> 0
<pfps> I agree with Holger about the meaning of high level
<pfps> to add unbounded maxcount we need to add a new piece of vocabulary - that has a decided cost
ericP: Machine generated code may benefit from an explicit value, so I am divided about this
<pfps> in a compact syntax the cost is much lower
<pfps> there is no overriding in SHACL, I hope
aryman_: Semantics are that you can only narrow down constraints.
RESOLUTION: Leave SHACL as is, but create a maxCount value in the high-level language that is interpreted as the maxCount default in SHACL
<pfps> I agree with Arthur
<pfps> adding in an explicit OPEN would just be adding in extra vocabulary, which has a cost, for expressive purpose
aryman_: Karen is advocating this based on feedback from her user community. Their mindset may be different from what is needed in SHACL. On the long term adding extra syntax may actually confuse other users.
... a more consistent language is easier to learn.
Arnaud: We could put this as a statement into the document - no constraint triple means unconstrained.
Which ticket number is this?
<Arnaud> http://www.w3.org/2015/12/10-shapes-minutes.html#resolution02
Dimitris: It was ISSUE-103 but we left sh:ClosedShape out of that resolution.
<Arnaud> resolution was: Close ISSUE-103, accepting the proposed simplification except for closed shapes which should be treated differently
Arnaud: So we cannot rely on this to resolve Karen's issue.
<pfps> so the idea is to retain closed constraints?
Dimitris: One issue was what would happen with multiple closed shape statements.
Arnaud: Maybe we could close 102 and open a new issue on closed shapes
+1
<Arnaud> PROPOSED: Close ISSUE-102, based on resolution for maxCount and leaving the question of how closed shape are specified to a separate issue
+1
<pfps> +1
<aryman_> +1
<Dimitris> +1
RESOLUTION: Close ISSUE-102, based on resolution for maxCount and leaving the question of how closed shape are specified to a separate issue
<Arnaud> ISSUE-115
<trackbot> ISSUE-115 -- Current way of specifying closed shapes is not satisfactory -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/115
<Arnaud> PROPOSED: Open ISSUE-115
aryman_: Question to Eric. Looking at the actual SPARQL query in the spec, which only considers sh:property but not inverse properties.
... Is this intentional?
ericP: ShEx is symmetric because (?) nobody uses it.
... for now it's fine if we just go in one direction.
aryman_: In OSLC use cases we would like to also have inverse properties.
RESOLUTION: Open ISSUE-115
ericP: I very rarely (or never) came across use cases for inverse.
... two kinds of closeness: closeness of predicates, closeness of shape
<pfps> got to go now
<Arnaud> trackbot, end meeting