See also: IRC log
<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
<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
<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
-1,+1
<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)