See also: IRC log
access code is the meeting number?
<scribe> scribe: simonstey
<aryman> I am having trouble with the webex audio
<Labra> Me too
<Labra> I can't hear anything...
you are not connected
<Arnaud> that's because you're not on the call
to audio
<Arnaud> PROPOSED: Approve minutes of the 3 December Telecon: http://www.w3.org/2015/12/03-shapes-minutes.html
RESOLUTION: Approve minutes of the 3 December Telecon: http://www.w3.org/2015/12/03-shapes-minutes.html
<pfps> Looked good to me :-)
Arnaud: based on the input I got last week, I revised the schedule but haven't filled it in yet
... I already put the grid in place
... 6h timespan / day for 3 days
<pfps> schedule seems to be fine
Arnaud: lunch break is reduced to 30 mins
... I wanted to spend some time on looking at the important issues to discuss
... may everyone have a look at that list and check whether something is missing
http://www.w3.org/2014/data-shapes/wiki/F2F5#Important_issues_and_meta-issues_to_be_addressed
<pfps> I think that the abstract classes thing is meta-model, but a change of title would be fine.
[aryman will look for the issues relating to abstract classes currently defined in shacl.ttl]
<pfps> I fiddled with that item
Arnaud: my goal is to update the agenda with specific work items by the end of the week
... please note whether you are available for the VF2F at http://www.w3.org/2014/data-shapes/wiki/F2F5#People_planning_to_participate_remotely:
... I added categories to the tracker
Arnaud: issues can now be categorized according to https://www.w3.org/2014/data-shapes/track/products
... maybe some of the meta issues could be used as categories
+q
Arnaud: already existing issues can also be recategorized
issue-103
<trackbot> issue-103 -- Can we further simplify the syntax of some constraint types? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/103
<aryman> +1
Arnaud: the syntax we currently have is pretty heavy
... which is an area where e.g. ShEx proposes a way more compact syntax
aryman: I'm in favor of the simplification, but I don't agree with the proposal on how to simplify the definition of closed shapes
... I would lift the closed property to be a property of the shape rather than one of the constraint node
pfps: RDF encoded syntaxes are ugly.. there is no way around that
... I would like to have some sort of a principle of what's going on here
Arnaud: how much do you need to be able to say whether that makes sense?
pfps: everything
... it's not about beautifulness but if it's round
<pfps> I do agree that a move away from classes to properties is a good thing, but this should be done uniformly
<kcoyle> +1 to arthur's approach
aryman: I think we could go down the general direction of the proposal and let the editor's writing it down thoroughly
<kcoyle> +q
kcoyle: something has to be done to clarify what the default is CWA/OWA
[remove cwa/owa]
kcoyle: we really have to make it clear under which assumption we are operating, either cwa oder owa
Arnaud: we may fall into the realm of best practices, explaining what implications certain ways of representing shapes have
pfps: currently both shapes and constraints can be closed, afaik
<Dimitris> how will two separate closed constraints in a shape work?
pfps: but the name "closedshapeconstraint" may be misleading
aryman: in the current spec, the closeness is a property of a shape
... but it depends on other definitions thus shouldn't be treated in the same way; I would make it a seperate kind of shape
<pfps> agreed, having closed sit on a constraint is likely to lead to confusion. instead there should be a separate construct that closes a shope
aryman: we have to be sensible about the default
+1
<Dimitris> +1
<kcoyle> +1
<Arnaud> PROPOSED: Close ISSUE-103, accepting the proposed simplification except for closed shapes which should be treated differently
<Labra> +1
<kcoyle> +1
<Dimitris> +1
+1
<aryman> +1
<pfps> 0, major syntax changes need to be looked at only when there is a complete proposal
<TallTed> +1
Arnaud: we can reopen this issue whenever we think it's necessary and could even revoke the resolution
RESOLUTION: Close ISSUE-103, accepting the proposed simplification except for closed shapes which should be treated differently
issue-104
<trackbot> issue-104 -- Should sh:datatype and sh:class have better support for OR? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/104
I agree with pfps comment: "If this change is going to be made, then every case should be examined to see whether it deserves to have the same feature."
pfps: in a reasonable syntax there are ands and ors
... with a nice and clean syntax
... but we have the RDF pig, and we are proposing to shrink it by cutting out some fat but it may gets unrounder
... the () trick only looks nice in turtle
... here we would interpret rdf:list as or, but somewhere else we might treat it as and
... so one would have to look over all possible occurences of such lists and check whether the comply with the proposed semantics
aryman: ofc it's just syntactic sugar, but we have to get the readers to actually read our spec (i.e. make it more appealing)
... it's hard to go from nothing to full generality
[trade off between ease of use and ease of misuse]
<Arnaud> PROPOSED: Yes, as suggested in the ISSUE (use rdf:Lists for multiple options)
<Arnaud> PROPOSED: Close ISSUE-104, as proposed.
<aryman> +1
+q
<TallTed> +1
<kcoyle> +.5
<pfps> -0 I think that invisible or is too dangerous
<Dimitris> 0+
+1
<TallTed> the word is "abstain"
<Arnaud> PROPOSED: Close ISSUE-104, as proposed but every case should be examined to see whether it deserves to have the same feature.
+1
<Labra> +0
<aryman> +1
<kcoyle_> i lost power, back but just on irc
Dimitris: this may cause some difficulties for engines to parse the value of sh:class/datatype
... I would be happier to have a seperate property for this
we could also approve it for now and dimitris raises an issue for that
<Dimitris> Close ISSUE-104, as proposed but by changing the SHACL properties to sh:classOneOf and sh:datatypeOneOf
<pfps> that is certainly more obvious
<pfps> +0.5
aryman: we should may use the term "in" to be consistent with our current spec
<Arnaud> PROPOSED: Close ISSUE-104, as proposed, using the properties sh:classIn and sh:datatypeIn, and noting that every case should be examined to see whether it deserves to have the same feature.
<aryman> like sh:in
<aryman> yes
<aryman> +1
<pfps> +0.2
+1
<Labra> +0.5
<pfps> +0.5
<Dimitris> +.8
<TallTed> +0.i
<pfps> In my opinion, anyy syntax thrust should be on a compact syntax, not on trying to make the RDF encoding less ugly
RESOLUTION: Close ISSUE-104, as proposed, using the properties sh:classIn and sh:datatypeIn, and noting that every case should be examined to see whether it deserves to have the same feature
aryman: this discussion and pfps' concerns maybe mean to discuss the notion of a compact syntax for SHACL at the VF2F
Arnaud: is there any other issue we should discuss?
pfps: google phone is free, at least for north america
<aryman> is Google Voice the same thing as Google Phone?
[discussing reliability of and alternatives to webex]
<Arnaud> trackbot, end meeting