IRC log of shapes on 2015-10-29

Timestamps are in UTC.

18:15:41 [RRSAgent]
RRSAgent has joined #shapes
18:15:41 [RRSAgent]
logging to http://www.w3.org/2015/10/29-shapes-irc
18:15:43 [trackbot]
RRSAgent, make logs rdf-data-shapes
18:15:45 [trackbot]
Zakim, this will be SHAPES
18:15:45 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
18:15:46 [trackbot]
Meeting: RDF Data Shapes Working Group Teleconference
18:15:46 [trackbot]
Date: 29 October 2015
18:15:58 [TallTed]
q+
18:16:13 [ericP]
ack next
18:16:49 [pfps]
I"m OK with opening this - if the issue is broadened later that's fine
18:17:06 [aryman]
ISSUE-104 is about a simpler syntax for allowing unions of datatypes or classes
18:17:12 [ericP]
APPROVED: open issue-104
18:17:24 [ericP]
topic: requirements
18:17:34 [aryman]
TOPIC: Requirements
18:17:49 [pfps]
q+
18:17:57 [ericP]
-> https://docs.google.com/document/d/1whx2DeJtng-WZXo2DAHc_GZL7ElXNS_B8fBxarGA-0o/ google doc of requirements
18:18:03 [ericP]
ack next
18:18:43 [kcoyle]
"addressing" requirements?
18:19:14 [kcoyle]
q+
18:19:23 [aryman]
ericP: who has reviewed the Google doc?
18:19:34 [aryman]
pfps: Looks good
18:19:35 [ericP]
ack next
18:19:47 [TallTed]
perhaps change "Solution" to "Satisfied? By?"
18:20:02 [pfps]
This could be in UC&R, either concentrated or spread out.
18:20:52 [pfps]
I like "satisfied by" as well
18:23:22 [ericP]
q?
18:24:06 [kcoyle]
ACTION: kcoyle to send email to group with unclear "satisfied by's"
18:24:06 [trackbot]
Created ACTION-30 - Send email to group with unclear "satisfied by's" [on Karen Coyle - due 2015-11-05].
18:24:23 [pfps]
Right the satisfied by column should point to the "solution"
18:26:18 [ericP]
topic: ISSUE-93
18:27:39 [pfps]
There are three things - the SHACL language, the SHACL validation process, and good style for SHACL shape document
18:28:36 [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
18:28:50 [aryman]
hsolorig: the spec does not clearly separate RDF syntax and semantics and conformance for processors
18:29:11 [aryman]
s/hsolorig/hsolbrig/
18:29:48 [aryman]
hsolorig: propose to use formatting to distinguish type of info
18:30:00 [hknublau]
hknublau has joined #shapes
18:30:03 [hsolbrig]
s/hsolorig/hsolbrig/
18:30:11 [TallTed]
SHACL authoring tool -> SHACL shape document -> SHACL-based validation processor *or* SHACL-based form constructor *or* other thing
18:32:04 [pfps]
what are the other goals (besides validation)? Is anyone working on this?
18:32:20 [pfps]
q+
18:33:39 [hknublau]
present+ hknublau
18:33:48 [aryman]
TallTed: need to address other kinds of processors besides validators
18:34:24 [ericP]
ack next
18:35:08 [aryman]
pops: need to tighten up spec language to refer to validation versus a generic engine
18:35:22 [aryman]
s /pops/pfps/
18:36:04 [pfps]
if anyone wants the other uses of SHACL to survive then someone has to do the work
18:36:08 [aryman]
aryman: fyi, my browser keeps autocorrecting names
18:37:10 [pfps]
q+
18:37:49 [aryman]
ericP: asks TallTed if he will look at these other aspects of SHACL, such as UI forms
18:37:53 [pfps]
q-
18:38:25 [hsolbrig]
q+
18:39:14 [TallTed]
that's the third. documentation, forms generation, and data validation.
18:39:23 [aryman]
hsolbrig: I am interested in generating documentation from SHACL
18:40:28 [ericP]
topic: ISSUE-94
18:40:32 [pfps]
there is no way that I can be at all sensitive to something that is not defined
18:40:48 [ericP]
topic: ISSUE-95
18:41:17 [ericP]
topic: ISSUE-94
18:41:33 [pfps]
q-
18:42:39 [pfps]
q+
18:42:47 [ericP]
ack next
18:43:01 [ericP]
ack next
18:43:35 [aryman]
hsolbrig: this issue is about referring to RDF syntax, e.g. rdf:List
18:44:05 [aryman]
pfps: All we have is the RDF syntax so we need to refer to it
18:45:21 [aryman]
ericP: we could possibly encode the syntax rules in the shacl.shacl document, or else define an abstract syntax
18:46:16 [aryman]
pfps: not sure if an abstract syntax would help
18:46:38 [pfps]
without a different syntax for SHACL it is somewhat hard to separate the document from the RDF encoding of SHACL
18:47:17 [pfps]
the document does need a full rewrite to make the distinction between syntax and validation more obvious
18:48:05 [aryman]
q+
18:48:30 [Labra]
Labra has joined #shapes
18:48:38 [ericP]
ack next
18:49:07 [ericP]
aryman: we need a vocabulary
18:49:14 [pfps]
one problem with the shacl document that described shacl syntax was that it embodied much more than is in the specification
18:49:27 [ericP]
... the shacl.shacl had 1000+ lines and contained many more terms than are in the spec
18:49:38 [pfps]
hence the posts from Arthur and myself concerning ISSUE-95
18:49:52 [ericP]
... we should have a spec with an agreed vocab, only putting terms in the vocab if they're mentioned in the spec.
18:50:22 [pfps]
I would make this even stronger - the terms have to have some rationale for being in the spec
18:52:37 [pfps]
q+
18:53:12 [Labra]
+present labra
18:53:26 [hknublau]
q+
18:54:16 [aryman]
I propose that we coordinate efforts to create a normative vocabulary document for SHACL
18:54:27 [aryman]
the source should be Turtle in github
18:54:40 [aryman]
we can autogenerate HTML
18:54:59 [aryman]
this process has been used at IBM, OSLC, and OASIS
18:55:22 [ericP]
ack next
18:55:26 [aryman]
looking for volunteer to be lead editor of the vocab
18:56:57 [aryman]
pfps: I am not advocating the separation of the syntax and semantics
18:57:12 [ericP]
ack next
18:57:31 [aryman]
pfps: however if that happened I wouldn't object
18:57:34 [pfps]
and so I would be willing to put any effort into the separation
18:58:24 [aryman]
hknublau: I already have a Turtle file
18:58:29 [aryman]
q+
18:58:35 [ericP]
ack next
18:58:41 [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
18:58:57 [ericP]
aryman: there's a subset of shacl.shacl which is just fine but there is a lot of other stuff.
18:59:17 [ericP]
... there is more that is not mentioned in the spec than that which is mentioned in the spec
18:59:31 [pfps]
q+
19:00:02 [ericP]
ack next
19:00:59 [pfps]
i didn't get that impression of the ttl file - I found lots of stuff there that went beyond the spec
19:02:00 [ericP]
aryman: let's start with the subset of terms that have a rationale in the spec
19:02:05 [aryman]
aryman: what about all the terms not discussed in the spec?
19:02:45 [aryman]
pfps: agree that Holger's Turtle file has lots of terms that are not needed
19:03:11 [aryman]
pfps: the spec should contain the least number of terms necessary
19:03:12 [pfps]
specs should be about doing the least that is necessary
19:03:47 [aryman]
ericP: reading the additional terms is a burden on readers
19:03:53 [pfps]
q+
19:04:00 [ericP]
ack next
19:04:12 [aryman]
ericP: propose that Holger should create a subset of the doc
19:04:32 [aryman]
pfps: disagree since there are circularities
19:04:59 [aryman]
q+
19:05:22 [hknublau]
q+
19:06:14 [aryman]
pfps: Holger is treating SHACL as a modelling language, which is contrary to W3C guidance, and is contrary to what I believe SHACL should be
19:07:19 [ericP]
ack next
19:08:14 [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
19:08:53 [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
19:10:23 [kcoyle]
+1 to arthur's analysis
19:10:24 [ericP]
aryman: i think it's elegant that shacl can describe itself, but it's not clear. we need a separate vocab doc.
19:10:40 [ericP]
... hknublau is passionate about the combination of shapes and classes.
19:10:51 [ericP]
... and we'll keep debating it
19:10:54 [ericP]
ack next
19:11:56 [aryman]
hknublau: hard to distinguish between a modelling language and a schema language
19:12:14 [aryman]
knublau: what are you proposing?
19:12:16 [aryman]
q+
19:12:36 [ericP]
aryman: i'm proposing a plain old rdfs document.
19:12:49 [ericP]
... it's hard to define shacl in terms of shacl.
19:13:08 [ericP]
... start by defining the terms and then add the constraints
19:13:21 [ericP]
... the constraints are what's missing from OWL and RDF-S
19:13:38 [ericP]
q+ to discuss XML Schema for XML Schema
19:13:39 [aryman]
q+
19:14:00 [kcoyle]
straw vote?
19:14:06 [TallTed]
q+
19:14:20 [ericP]
kcoyle, i'm trying to figure out what it would be
19:14:25 [ericP]
ack next
19:15:06 [ericP]
aryman: rationale for the speration of constraints and classes: use of a class depends on a context
19:15:26 [ericP]
... i'm coming from a linked-data world where there are individual docs
19:15:35 [ericP]
... you're coming from a database world
19:16:13 [kcoyle]
we need to handle both use cases
19:16:45 [ericP]
... we need to separate the classes from the shapes in order
19:17:15 [aryman]
aryman: we have different use cases, some require a separation of class versus shape since the shape depends on the context
19:17:38 [ericP]
ack next
19:17:39 [Zakim]
ericP, you wanted to discuss XML Schema for XML Schema
19:17:44 [ericP]
ack next
19:18:06 [aryman]
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
19:18:42 [aryman]
TallTed: I agree that we should not describe a language using the language that we are describing
19:19:16 [aryman]
TallTed: if people don't already understand SHACL then they won't understand a description of SHACL using SHACL
19:20:16 [aryman]
kcoyle: propose a straw poll on using plain old RDFS or OWL to describe SHACL versus using SHACL to describe SHACL
19:22:10 [kcoyle]
q+
19:23:13 [ericP]
ack next
19:23:33 [aryman]
ericP: we have several approaches 1) a modified shacl.shacl, 2) a RDFS or owl vocal, 3) abstract syntax, 4) plain English
19:24:27 [aryman]
kcoyle: just 1) and 2)
19:24:44 [aryman]
kcoyle: for the straw poll
19:24:58 [aryman]
s/vocal/vocab/
19:25:54 [aryman]
q+
19:26:40 [ericP]
ack next
19:26:55 [aryman]
kcoyle: we need to deliver an RDFS vocab for SHACL
19:27:32 [ericP]
aryman: i want a vocab document that defines the SHACL terms but does not use SHACL.
19:27:56 [ericP]
... if you look at Holger's doc, you can think of it as a union of two sets of docs.
19:28:11 [ericP]
... one part is the doc i want
19:28:33 [TallTed]
+1
19:28:33 [ericP]
... textually, people could read that doc without starting out understanding SHACL.
19:28:43 [ericP]
... the 2nd would eat our own dogfood.
19:28:49 [ericP]
q?
19:31:30 [aryman]
Straw poll: 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
19:31:49 [aryman]
-1,+1
19:32:03 [TallTed]
+0.5, +1
19:32:11 [ericP]
ericP: -0.5,+1
19:32:17 [hsolbrig]
0, +1
19:32:23 [Labra]
-0,+1
19:32:25 [kcoyle]
-1, +1
19:32:27 [Dimitris]
+0.3, +1
19:32:33 [hknublau]
+1, -0.5 (I think we could do both and generate the RDFS from the SHACL file)
19:32:34 [pfps]
-1, 0 (something has to be done to shacl.shacl, but I'm not convinced that separation is the right approach)
19:33:38 [hknublau]
hknublau has left #shapes
19:33:48 [ericP]
RRSAgent, generate minutes
19:33:48 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/10/29-shapes-minutes.html ericP
19:33:54 [ericP]
RRSAgent, make log public
19:53:12 [hknublau]
hknublau has joined #shapes
20:09:32 [hknublau]
hknublau has left #shapes
20:57:18 [Arnaud]
Arnaud has joined #shapes
21:56:08 [AxelPolleres]
AxelPolleres has joined #shapes
23:33:34 [AxelPolleres]
AxelPolleres has joined #shapes
23:43:28 [Zakim]
Zakim has left #shapes
23:43:45 [TallTed]
TallTed has joined #shapes