W3C

RDF Data Shapes Working Group Teleconference

13 Aug 2015

Agenda

See also: IRC log

Attendees

Present
Arnaud, pfps, simonstey, hknublau, labra, TallTed, aryman, kcoyle
Regrets
Dimitris
Chair
Arnaud
Scribe
simonstey

Contents


<scribe> scribe: simonstey

minutes of last week

<Arnaud> PROPOSED: Approve minutes of the 6 August Telecon: http://www.w3.org/2015/08/06-shapes-minutes.html

<pfps> minutes look fine to me

RESOLUTION: Approve minutes of the 6 August Telecon: http://www.w3.org/2015/08/06-shapes-minutes.html

Arnaud: iovka hasn't answered mails reg. constraints for the f2f meeting yet
... will come back to this once she answers her mails

SHACL FPWD

Arnaud: we should get a FPWD of the spec out rather sooner than later
... there is interest of people outside the WG to have a first look at the FPWD
... although we've not solved all open issues we could still publish whatever we have at this point. of course under the right disclaimer that we have decided to use this approach as our main approach but are open for feedback

pfps: there are still some issues that are present for months now that must be solved before publishing a FPWD
... nominclature is still broken too

Arnaud: holes in the spec e.g. recursion should be stated within a disclaimer

aryman: before publishing the document we might want to think of adding a 2nd editor to the draft
... e.g. peter if he has time
... we should wrap up the discussion under ISSUE-66 regarding recursion

hknublau: I would also like to see the spec published sooner than later, but my hands are tied too
... I can't just make changes

<pfps> holger has brought up a very important point - there is not enough work being done in the working group

Arnaud: you can do whatever you want with the spec iff your changes are only editorial

pfps: the document is completely broken and I would love to be the editor but I can't be it for the current document

TallTed: according to peter there are a lot of inconsistencies in the document
... pointing at inconsistencies and fixing them requires different amounts of work

Arnaud: maybe we have to think of how to fix the draft in a way that it doesn't suck as much rather than just postponing its publication

<TallTed> "At Risk" is an entirely viable flag...

pfps: I would rather get us away from the iceberg rather than try to rearrange the chairs on the titanic
... I want not to be editor of the document in its current form
... I think I've proposed an approach that solves most of the issues so why should I then try to fix an approach that is completly broken

TallTed: maybe because you are the only one who sees those issues

pfps: there are some passages in the document that counter others in the document
... especially wrt. to the nominclature
... if someone cares for the current nominclature they should try to fix those issues

<hknublau> http://www.w3.org/2014/data-shapes/track/issues/65

aryman: peter, do you have also proposed a possible solution for your issues or were you just pointing them out because they might be too difficult to solve?

pfps: I'm claiming that someone should have already looked into this issue
... I'm not the editor of the spec, should I make changes then?
... people are not seeing the underlying problem that I'm seeing
... someone else should put effort into this WG except me

<Arnaud> PROPOSED: Publish current editor's draft, making it clear that this is still very much work in progress and that feedback is requested on the general direction

pfps: 1) the WG could decide that the current draft is suitable for publication 2) they could identify minor changes that should be made to get it published 3) there are major changes that should be made

<aryman> -1

<pfps> -1 because the document has not had any review form the working group

+0.5

<pfps> I agree strongly with Aurhur

aryman: we need a certain period of time to be able to review the document
... a minimum of 2 weeks should be sufficient

<pfps> The document has gone through dramatic changes since I last looked at in detail

Arnaud: what about trying to publish it before our f2f meeting i.e. 3rd of september

TallTed: there are two classes of problems we might have to face -> 1) we have to completely rework that before being able to publish it 2) we have to somehow fix this issue
... it's just a FPWD and not a recommendation

Arnaud: people outside the WG are talking on a much higher level than the issues we are discussing about
... I claim that the current draft is sufficient enough to retrieve that kind of feedback

aryman: In our requirements we clearly stated that understanding SPARQL should not be required

Arnaud: if the core is too limited than in practice people will just use templates and would have to use SPARQL

<TallTed> I have just edited the nomenclature issue to make it such...

<TallTed> 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

hknublau: we need to take external feedback with a grain of salt here, I'm definitly interested in receiving such feedback
... I'm happy to add additional features to the core language if one would come up with them

<TallTed> "SHACL recipes"

Arnaud: I do think that we need a core that is able to address ~80% of our use cases

<pfps> I think that the current core meets the uses that Nuance wants to use

Arnaud: peter, we can certainly try to solve issues you've raised but you can't except us to fix them in a way you like if we have no insights in the problems you have with the document

pfps: I voted to use the document in its current form
... I didn't try to transform this document to look like my proposal but to transform it into something that could actually be used

I'm working with holger's implementation and they actually do work

s

Arnaud: there are two sides here, peter is frustrated that his issues are not going to be addressed

<pfps> the spec (at least as I reviewed it) goes into an infinite loop in spots - is there an implementation that works this way?

Arnaud: and other are frustrated because they don't see those issues

<hknublau> I will look at issue 65

Arnaud: my proposal is to give people 3 weeks to have a look at the spec, read it and figure out if there are parts of it that would prohibit it of being published as a FPWD

<hknublau> @pfps: Fixes to the recursion issue have been proposed but I am not entitled to update the spec until they are not resolved

ISSUE-72

<Arnaud> issue-72

<trackbot> issue-72 -- Qualified Cardinality Restrictions -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/72

<pfps> close the issue - QCRs are good

<Arnaud> PROPOSED: Close ISSUE-72, adopting sh:qualifiedValueShape as currently specified in editor's draft

Arnaud: I would like to have opinions from people regarding this issue

<hknublau> +1

<pfps> +1

+1

<pfps> a QCR is something like "two children who are lawyers" without saying that all children are lawyers

<pfps> with QCRs you can say "two children who are lawyers and two children who are doctors"

hknublau: is counting values of properties that have a certain shape; e.g. property parent -> a constraint would make sure that one parent object is male and one is a female

<kcoyle> +1

<TallTed> +1

<aryman> +1

RESOLUTION: Close ISSUE-72, adopting sh:qualifiedValueShape as currently specified in editor's draft

ISSUE-58

issue-58

<trackbot> issue-58 -- Signalling closed shapes/Defining closed shapes -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/58

<pfps> the design in the document is fine by me

<Arnaud> http://w3c.github.io/data-shapes/shacl/#ClosedShape

<pfps> it would be nice to get some ShEx person to approve the design

kcoyle: I'm wondering how this interfers with closing issue 44

issue-44

<trackbot> issue-44 -- How to express dependencies between graphs -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/44

<pfps> This is independent of graph-shape association or shape-node association

aryman: in the ShEx-inspired Core SHACL Semantics document they allow you to specify more finegrained notions of open shapes.

<aryman> http://w3c.github.io/data-shapes/semantics/

<aryman> This is defined in the grammar rule: OpenShape ::= 'open' InclPropSet? ShapeExpr

<pfps> oops - I forgot that there are exclusions on properties in 4.5 - I think that there should be no such exclusions

TallTed: what seems semi--open in shex is a closed shape in SHACL

pfps: what shex has is the notion of exluding certain properties
... there are bits of shex that cannot be expressed in shacl as of now

<TallTed> +1 to that

pfps: type and nodeshape are important in this respect

<pfps> the current document has exceptions for rdf:type and sh:nodeShape - I don't think that there should be these exclusions - if the effect is wanted you can just put in a vacuous constraint on rdf:type or whatever

aryman: I think naming them closed/open shapes aligns with CWA and OWA

<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jul/0114.html

<pfps> adding in the equivalent of the ShEx ignored properties is fine

<Arnaud> PROPOSED: Close ISSUE-58, as proposed by Holger in his email: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jul/0114.html

<hknublau> +1

hknublau: I've proposed a possible suggestion to the issue of exluding rdf:type/sh:nodeshape from evaluation of closed shapes in previous linked mail

<pfps> +1

+1

<TallTed> +1

<aryman> +1

<kcoyle> +0

RESOLUTION: Close ISSUE-58, as proposed by Holger in his email: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jul/0114.html

ISSUE-53

issue-53

<trackbot> issue-53 -- Multi-occurrence of the same predicate -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/53

<pfps> multioccurence is adequately handled in the current design - differently from ShEx but that's fine by me

<pfps> is there a pointer to the pushback??

<pfps> multioccurence is currently conjunction - in (some versions of) ShEx it is more like addition

<Arnaud> labra?

<hknublau> I see no problem with the current draft.

Arnaud: I've put it on for discussion because Holger's email started with "if I understood jose's intention correctly.."

aryman: maybe our concept of qualifiedcardinalityconstraints should be generalized to be able to work for any constraints

pfps: QCRs as handled by the current spec work just fine for specifying such kinds of constraints

<pfps> the glitch before was that most conditions were like "between 2 and 3 children and all of them doctors" combining conditions like these can be a bit silly

<pfps> yes, the current design is fine

<Arnaud> PROPOSED: Close ISSUE-53 as addressed by the current editor's draft with sh:qualifiedValueShape

<hknublau> +1

<pfps> +1

+1

<aryman> +0.5

<TallTed> +1

<kcoyle> +0

RESOLUTION: Close ISSUE-53 as addressed by the current editor's draft with sh:qualifiedValueShape

<hknublau> straw poll on 23?

aryman: I thought the resolution to that issue was that people could do so if they want to do it

Arnaud: there was no such resolution

ISSUE-23

ISSUE-23

<trackbot> ISSUE-23 -- Shapes, classes and punning -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/23

<pfps> the question is whether there is something special about a class that is also a shape

Arnaud: the current draft allows different kinds of association

<aryman> my understanding is that there is nothing special about a Shape also being a Class

Arnaud: attach it to a class, to an individual, ...

pfps: there are a whole lot of reasons not to allow shapes being classes
... it turns SHACL into a modelling language where we have documents that look like RDFS documents but aren't

<pfps> the real bad thing is that SHACL will then have documents that look like RDFS but don't act like RDFS

Arnaud: we have to definitly look into this issue if this interfers with RDFS inference

aryman: is there any special treatment for shapes being classes?

hknublau: yes, if there is a type link pointing to a shape this will be interpreted as sh:nodeshape

<Arnaud> https://w3c.github.io/data-shapes/shacl/#scopeClass

aryman: if you have a shape defined i.e. as shex then you don't have it as rdf triples

<Arnaud> PROPOSED: Close ISSUE-23, as currently specified in editor's draft, allowing the rdf:type to be used to associate a shape, which is also a class, to a node

<hknublau> +1

<pfps> One of the problematic aspects here is that special things need to be done, e.g., state that classes are subclasses of rdfs:Resource. This is a consequence of RDFS, but not here.

<pfps> -1

Arnaud: you have a node and a type arc that points to a class, if this class is then a shape too then those constraints must hold for that node

<hknublau> @pfps, no the subclass triple is not needed

<pfps> Then why are they there?

<hknublau> @pfps neither do I see anything else that violates RDFS

<hknublau> I already exaplained this in email

<kcoyle> +0

TallTed: since those bits are just of contextual nature I don't think the concers matter here

+1

<aryman> +0

<TallTed> +1

<hknublau> (Thanks to those who don’t really care to vote 0 and not -1 on this, it’s important to me)

<Arnaud> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 6 August Telecon: http://www.w3.org/2015/08/06-shapes-minutes.html
  2. Close ISSUE-72, adopting sh:qualifiedValueShape as currently specified in editor's draft
  3. Close ISSUE-58, as proposed by Holger in his email: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jul/0114.html
  4. Close ISSUE-53 as addressed by the current editor's draft with sh:qualifiedValueShape
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2015/08/21 21:11:30 $