See also: IRC log
* I am trying to connect through webex but something different occurs...it is asking by room ID?
<Arnaud> 646 464 360
<Arnaud> it's on the agenda
<Arnaud> I don't know why it has become like that, we have to go through that step every time now
* password?
Now I can hear
if you want to scribe, I can do
but no talking on my side :)
<Arnaud> PROPOSED: Approve minutes of the 31 March 2016 Telecon: http://www.w3.org/2016/03/31-shapes-minutes.html
<Arnaud> scribe: labra
<pfps> looked ok
RESOLUTION: Approve minutes of the 31 March 2016 Telecon: http://www.w3.org/2016/03/31-shapes-minutes.html
Arnaud: Several issues are in the agenda...some of them can be later
<pfps> i think that it would be worthwhile to discuss 134 today.
Arnaud: some of them through the mailing list
<Arnaud> PROPOSED: Close ISSUE-80, adding sh:stem to the spec outlined in Eric's email https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0311.html
<ericP> +1
<simonstey> +0
+1
<pfps> 0
<kcoyle> +1
<hsolbrig> +0
<Dimitris> 0
<jamsden> 0
<hknublau> 0
RESOLUTION: Close ISSUE-80, adding sh:stem to the spec outlined in Eric's email https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0311.html
Arnaud: Next issue sh:abstract seems not to be relevant any longer
... we wanted to close it some time ago
<Arnaud> PROPOSED: Close ISSUE-78, without adding sh:abstract, given that sh:ShapeClass was dropped
<simonstey> +q
Arnaud: there is a tension between how much SHACL should be a data modeling language
... the groups is mainly against that, after a long discussion there was some compromise
<simonstey> -q
Hsolbrig: Let's say we define a class and it has several subclasses...
... and I want to specify that it is abstract so there is no instance of it
<Arnaud> issue-78
<trackbot> issue-78 -- Should SHACL support marking classes as abstract -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/78
Hsolbrig: for OSLC it means there is no creation dialog
Holger: that's exactly the use case that we have
... with the redefinition of the metamodel it is no longer needed...
... but we have used it
... we could use it in another namespace and don't worry about shacl
jamsden: the argument is that we don't need that particular constraint
... it is a useful property to have and a very common thing to do when defining vocabularies
... I would not be in favour of dropping it
<simonstey> +q
<Zakim> ericP, you wanted to describe uses of "abstract"
<kcoyle> I don't find a use case that matches this
ericP: the use case was I want to have a notion of hierarchy and there was a semantics of abstract
... but my understanding is that we are not there yet...we don't have the notion of subshapes
... and how to derive shapes
simonstey: would like to ask if there are other constraints that apply to nodeConstraint
Arnaud: I don't feel confortable to close it dropping because it seems there are people who see it useful
<hknublau> @simonstey sh:closed is also used as NodeConstraint only
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-78:_Abstract_Classes
Arnaud: there is a link to the proposal page with some discussion a while ago
... Peter's objection was that it was not well defined
... those who care should improve the proposal
pfps: I objected because if was not well enough defined
<hknublau> Any SHACL feature that is removed from core can be covered by extension vocabularies.
<simonstey> +q
simonstey: maybe the problem is the name
...sh: abstract seem to have a problem and we could it call differently
... we are not modelling something, if we define a node constraint with sh:abstract = true we just want to say that this class has no instances...
... in the end, maybe, it's just the naming
kcoyle: can this be handled with the cardinality constraints?
we could do it constraining the cardinality of rdf:type
<hknublau> It interacts with inferencing (or not), so this is a slippery slope.
ericP: not really, we could have student, teacher that derive from person
... some explanation
Arnaud: is there any one who wants to try a better proposal?
<jamsden> I'll give it a try
Holger: My other proposal was to define the property without semantics and just as an annotation
... it's just as sh:name
<simonstey> +q
Holger: it doesn't lead to validation errors
simonstey: the danger of defining just as an annotation is that it goes more as a modelling construct
... there may be some conflicts with a modeling language
pfps: there may be several problems with it
<pfps> OK
<Arnaud> PROPOSED: Close ISSUE-136, renaming sh:equals, sh:notEquals, sh:lessThan, sh:lessThanOrEquals to sh:equalProperty, sh:notEqualProperty, sh:lessThanProperty, sh:lessThanOrEqualProperty respectively
<simonstey> +q
<hknublau> +1
simonstey: What's a lessThanProperty?
<TallTed> equalValue makes much more sense to me than equalProperty
<kcoyle> TT - I, too, suggested equalValue
<TallTed> or valueEqual, valueLessThan ... or propertyValueEqual, propertyValueLessThan?
Holger: one problem with lessThan leaving lessThanProperty
... I also like disjoint
<TallTed> Bob, Jim, Fred!
Arnaud: problem with names
... who cares to give a proposal?
<hknublau> PROPOSED: sh:equalPropertyValues, sh:disjointPropertyValues, sh:lessThanPropertyValues, sh:lessThanOrEqualsPropertyValues
<Dimitris> values or value?
kcoyle: Ted and I have the feeling that having the word value
... is better
Holger: it is important to include property
<ericP> you need a "*" operator for dereferencing
pfps: we are seing another problem with the general syntax of SHACL
... the division of propertyConstraint, nodeConstraint and inverse...
... there is very few intuition...
... it doesn't matter, it will still be horrible
jamsden: I agree with all of the above
... I would rather use commonly used names rather than long a precise names
TallTed: I am sympathetic to some of what Peter has already said
... we need clear names and labels for these things
... we may use opaque labels
<pfps> I rather like sh:∅ as the replacement for sh:notEquals
<Dimitris> if we use PV as suffix? e.g. equalsPV
<hknublau> Please decide one way or another. I don't like the dragging on.
kcoyle: we should try for shorter names
Arnaud: the names as they are, are short
... maybe they are misleading, but people will learn
<pfps> sh:notEquals is not equal to the negative of sh:equals
TallTed: do we need equal and notEqual when we already have not?
<pfps> sh:lt and sh:lte cannot be defined in terms of the other
pfps: I proposed sh:notEquals to be sh:disjoint
<Arnaud> PROPOSED: Close ISSUE-136, keeping sh:equals, sh:lessThan, sh:lessThanOrEquals, changing sh:notEquals to sh:disjoint
<simonstey> +1
<hknublau> 0
<pfps> +1
0
<hsolbrig> 0
<TallTed> ... sh:propertyValueEqual, sh:propertyValueDisjoint, sh:propertyValueLT, sh:propertyValueLTE, sh:propertyValueGT, sh:propertyValueGTE ...
<Dimitris> +.5
<pfps> sh:gt can easily be defined in terms of sh:lt
<Dimitris> equalsWith / disjointWith?
<kcoyle> +.5
<jamsden> if equal means same literal or URI, then that seems pretty clear
<pfps> NO
RESOLUTION: Close ISSUE-136, keeping sh:equals, sh:lessThan, sh:lessThanOrEquals, changing sh:notEquals to sh:disjoint
<Arnaud> issue-96
<trackbot> issue-96 -- Should the validation results contain stable IDs to indicate the type of violation -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/96
<Arnaud> PROPOSED: Close ISSUE-96, adding an ID to validation results for each constraint type. All open proposals include URIs for each constraint component, and these align with the mechanism used by the extension mechanism.
Holger: all of the proposals have the notion or something comparable to constraint components (templates)
... each of those components can produce certain types of constraint violations
... for tools it would be good to know what kind of violation result it i
... if we use strings it is not ok
... as long as we agree that it should be done, then it is a matter to naming
<jamsden> could those URIs be enumeration literals (instances) of some error class
pfps: the results are too complex
... this is also unnecessary
... validation reports already point to the souce constraint, shape and template
... why should we add something else?
Holger: there is sourceConstraint which is responsible for the error
<Arnaud> PROPOSED: Close ISSUE-96, sh:sourceTemplate fulfill this needs
<simonstey> +1
<pfps> +1
<kcoyle> +0
<pfps> +1
<hsolbrig> 0
<jamsden> +1
<hknublau> +1
<Dimitris> +1
<TallTed> +1
0
RESOLUTION: Close ISSUE-96, sh:sourceTemplate fulfills this needs
<trackbot> issue-134 -- does SHACL syntax distinguish inverse property constraints -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/134
pfps: we are in a situation were figuring out where a shapes graph is ok
<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Apr/0021.html
pfps: in the normal case, it looks easy, but there may be several places that we should nail down in the spec
... to define what is a valid shacl document
... there are several holes and patches and more holes...
... in my recent email there are several cases where it is not clear what the answer is
Arnaud: how do we deal with invalid graphs?
... Holger said if it is invalid, let the implementation do what it wants...but there are more options...
<hknublau> For the record, I do not prefer the option to not define what happens. I just enumerated this as one option, if we don't have enough time in the WG.
Arnaud: it is fairly common to think what happens when the input is valid, but trying to know what happens when the input isn't is usually very hard
... in HTML it happened in HTML5
... because the web is full of broken HTML
... the XML Schema group there is a strict/lax mode
... this may be a compromise
... if we are in strict mode then the implementation stop and complains while in lax mode, it can do other things...
... I agree that the spec needs to address the corner cases
Holger: in the past we talked about creating a shapes graph for shacl
... I am of the opinion that there are several cases where this syntax must be enforced
... some rules are very important while others are less important
... if we have time, let's do it
... the issue of not doing this is that there is a lot unspecified
Dimitris: the shapes graph can be a grammar for the language
... it can be self-descriptive
... we don't need to define the edge cases
pfps: right now, it is not possible
... it may be a good idea, the problem is that you are saying that the language is...this program...
... I hope there should be other ways to describing the language
... I would say the first thing we have to is define what is in the language and what is not
... first of all, we have to decide what is in the language
Dimitris: we can define a set of basic shapes
* I lost part of what Dimitris said
pfps: Depending on shacl to define the syntax of shacl is problematic
... we should have some clearly wording of what is a shacl graph and what is not
... we are not even there yet
... there should be a way to define what is a valid shapes graph and what is not
... in the current design of shacl there are more and more bits that defy my intuition
Arnaud: there seems to be a great problem with the syntax
<pfps> The situation is not as stark as that, I think. The common situations should be OK and should work right.
hknublau: It is easy to criticise things, but it is difficult to fix them
... it is easy to give the impression that something is broken, but the language isn't broken
... what we should do is to go throught the issues and tickets
jamsden: I would like to offer some help to solve the issue
... it seems the peter and holger have the knowledge to solve it, I wonder if it would make sense for them to have a face to face
to solve those issues
scribe: sometimes those face to face meetings are productive
<pfps> I'm confused. What are the two conflictting approaches?
hknublau: there are other people who have the background to help
... I would like to have some task force to solve it outside of these time slots
... we are all in 3 different continents and it's hard to do a face 2 face
Arnaud: I agree that it seems some of these needs more work and talking
TallTed: It is true that our calls are shorts (although long)
... one of things to recognize is that we are different people with different styles
... peter's style is sometimes frustrating when he says is completely broken
Arnaud: It might be worth to have some extra times
... maybe we should have a long call (2/3 hours) on one issue
<hknublau> sounds good
Arnaud: maybe it is not necessary to have all the people, just the people interested
pfps: we cannot go anywhere without solving the fundamental problems
Arnaud: I would propose to have some time and do a poll to have some discussion
<TallTed> I wonder about more-and-more"fundamental problems" that are found on every read through
<Arnaud> trackbot, end meeting