RDF Data Shapes Working Group Teleconference

29 Oct 2015


See also: IRC log


kcoyle, hsolbrig, aryman, pfps, dimitris, eric, TallTed, hknublau, labra



<ericP> PROPOSED: Approve minutes of the 22 October Telecon: http://www.w3.org/2015/10/22-shapes-minutes.html

<pfps> The minutes looked fine to me.

<pfps> Minimum criteria is that the resolutions are OK

RESOLUTION: Approve minutes of the 22 October Telecon: http://www.w3.org/2015/10/22-shapes-minutes.html

<Dimitris> there is some echo from aryman & Harold

<scribe> scribenick: aryman

<scribe> scribe: aryman

<pfps> there were some posts to the WG mailing list that came from a non-mmemer

<pfps> are these posts official comments? if so they should be tracked, and there should not have been a response from the WG

<scribe> agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings#Next_Meeting

Alien posts to WG list

<kcoyle> this happened before: ttp://ibt.uk/A006P4I

ericP: we need to be careful about patent issues when dealing with alien posts to mailing list

Disposal of Raised Issue: ISSUE-104 Better support for sh:Or

<kcoyle> oops, ignore that link... this is the link: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Aug/0056.html

<ericP> http://piratepad.net/shacl

<kcoyle> ISSUE-104

<trackbot> ISSUE-104 -- Should sh:datatype and sh:class have better support for OR? -- raised

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

<ericP> trackbot, start meeting

ISSUE-104 is about a simpler syntax for allowing unions of datatypes or classes

RESOLUTION: open issue-104


<ericP> google doc of requirements

<kcoyle> "addressing" requirements?

ericP: who has reviewed the Google doc?

pfps: Looks good

<TallTed> perhaps change "Solution" to "Satisfied? By?"

<pfps> This could be in UC&R, either concentrated or spread out.

<pfps> I like "satisfied by" as well

<kcoyle> ACTION: kcoyle to send email to group with unclear "satisfied by's" [recorded in http://www.w3.org/2015/10/29-shapes-minutes.html#action01]

<trackbot> Created ACTION-30 - Send email to group with unclear "satisfied by's" [on Karen Coyle - due 2015-11-05].

<pfps> Right the satisfied by column should point to the "solution"


<pfps> There are three things - the SHACL language, the SHACL validation process, and good style for SHACL shape document

<pfps> The SHACL spec should have the first two - the third could be put into a primer, but that requires someone to write the primer

hsolbrig: the spec does not clearly separate RDF syntax and semantics and conformance for processors
... propose to use formatting to distinguish type of info

<TallTed> SHACL authoring tool -> SHACL shape document -> SHACL-based validation processor *or* SHACL-based form constructor *or* other thing

<pfps> what are the other goals (besides validation)? Is anyone working on this?

TallTed: need to address other kinds of processors besides validators

pfps: need to tighten up spec language to refer to validation versus a generic engine

<pfps> if anyone wants the other uses of SHACL to survive then someone has to do the work

aryman: fyi, my browser keeps autocorrecting names

ericP: asks TallTed if he will look at these other aspects of SHACL, such as UI forms

<TallTed> that's the third. documentation, forms generation, and data validation.

hsolbrig: I am interested in generating documentation from SHACL

<pfps> there is no way that I can be at all sensitive to something that is not defined


hsolbrig: this issue is about referring to RDF syntax, e.g. rdf:List

pfps: All we have is the RDF syntax so we need to refer to it

ericP: we could possibly encode the syntax rules in the shacl.shacl document, or else define an abstract syntax

pfps: not sure if an abstract syntax would help

<pfps> without a different syntax for SHACL it is somewhat hard to separate the document from the RDF encoding of SHACL

<pfps> the document does need a full rewrite to make the distinction between syntax and validation more obvious

aryman: we need a vocabulary

<pfps> one problem with the shacl document that described shacl syntax was that it embodied much more than is in the specification

aryman: the shacl.shacl had 1000+ lines and contained many more terms than are in the spec

<pfps> hence the posts from Arthur and myself concerning ISSUE-95

aryman: we should have a spec with an agreed vocab, only putting terms in the vocab if they're mentioned in the spec.

<pfps> I would make this even stronger - the terms have to have some rationale for being in the spec

I propose that we coordinate efforts to create a normative vocabulary document for SHACL

the source should be Turtle in github

we can autogenerate HTML

this process has been used at IBM, OSLC, and OASIS

looking for volunteer to be lead editor of the vocab

pfps: I am not advocating the separation of the syntax and semantics
... however if that happened I wouldn't object

<pfps> and so I would be willing to put any effort into the separation

hknublau: I already have a Turtle file

<pfps> there is also stuff in the ttl file pertaining to the implementation of the core constructs, isn't there? if so, this is controversial

aryman: there's a subset of shacl.shacl which is just fine but there is a lot of other stuff.
... there is more that is not mentioned in the spec than that which is mentioned in the spec

<pfps> i didn't get that impression of the ttl file - I found lots of stuff there that went beyond the spec

aryman: let's start with the subset of terms that have a rationale in the spec
... what about all the terms not discussed in the spec?

pfps: agree that Holger's Turtle file has lots of terms that are not needed
... the spec should contain the least number of terms necessary

<pfps> specs should be about doing the least that is necessary

ericP: reading the additional terms is a burden on readers
... propose that Holger should create a subset of the doc

pfps: disagree since there are circularities
... Holger is treating SHACL as a modelling language, which is contrary to W3C guidance, and is contrary to what I believe SHACL should be

<pfps> my view is that the shacl spec should not depend on the reference implementation of shacl, including those things that ended up in shacl.shacl

<ericP> pfps: there are many things in the shacl.shacl that shouldn't be there; some things missing from shacl.shacl, and some stuff in the spec which are only there because they were in the original shacl.shacl

<kcoyle> +1 to arthur's analysis

aryman: i think it's elegant that shacl can describe itself, but it's not clear. we need a separate vocab doc.
... hknublau is passionate about the combination of shapes and classes.
... and we'll keep debating it

hknublau: hard to distinguish between a modelling language and a schema language

knublau: what are you proposing?

aryman: i'm proposing a plain old rdfs document.
... it's hard to define shacl in terms of shacl.
... start by defining the terms and then add the constraints
... the constraints are what's missing from OWL and RDF-S

<kcoyle> straw vote?

<ericP> kcoyle, i'm trying to figure out what it would be

aryman: rationale for the speration of constraints and classes: use of a class depends on a context
... i'm coming from a linked-data world where there are individual docs
... you're coming from a database world

<kcoyle> we need to handle both use cases

aryman: we need to separate the classes from the shapes in order
... we have different use cases, some require a separation of class versus shape since the shape depends on the context

<Zakim> ericP, you wanted to discuss XML Schema for XML Schema

ericP: fyi, the schema for XML schema exists as an appendix to the XML Schema spec but is not used to define or teach XML Schema

TallTed: I agree that we should not describe a language using the language that we are describing
... if people don't already understand SHACL then they won't understand a description of SHACL using SHACL

kcoyle: propose a straw poll on using plain old RDFS or OWL to describe SHACL versus using SHACL to describe SHACL

ericP: we have several approaches 1) a modified shacl.shacl, 2) a RDFS or owl vocab, 3) abstract syntax, 4) plain English

kcoyle: just 1) and 2)
... for the straw poll
... we need to deliver an RDFS vocab for SHACL

aryman: i want a vocab document that defines the SHACL terms but does not use SHACL.
... if you look at Holger's doc, you can think of it as a union of two sets of docs.
... one part is the doc i want

<TallTed> +1

aryman: textually, people could read that doc without starting out understanding SHACL.
... the 2nd would eat our own dogfood.

STRAWPOLL: 1) status quo of shacl.shacl as per Holger's current doc, 2) separate into a pure vocab doc, plus a shacl doc for validation


<TallTed> +0.5, +1

<ericP> ericP: -0.5,+1

<hsolbrig> 0, +1

<Labra> -0,+1

<kcoyle> -1, +1

<Dimitris> +0.3, +1

<hknublau> +1, -0.5 (I think we could do both and generate the RDFS from the SHACL file)

<pfps> -1, 0 (something has to be done to shacl.shacl, but I'm not convinced that separation is the right approach)

Summary of Action Items

[NEW] ACTION: kcoyle to send email to group with unclear "satisfied by's" [recorded in http://www.w3.org/2015/10/29-shapes-minutes.html#action01]

Summary of Resolutions

  1. Approve minutes of the 22 October Telecon: http://www.w3.org/2015/10/22-shapes-minutes.html
  2. open issue-104
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2015/11/05 23:04:10 $