RDF Data Shapes Working Group Teleconference

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

Admin

<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 :-)

VF2F5

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

ISSUE categorization

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: Syntax simplifications

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: Union ranges

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?

http://www.timeanddate.com/worldclock/fixedtime.html?msg=RDF+Data+Shapes+meeting&p1=175&iso=20151215T1015

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