IRC log of shapes on 2015-09-08

Timestamps are in UTC.

07:48:40 [RRSAgent]
RRSAgent has joined #shapes
07:48:40 [RRSAgent]
logging to http://www.w3.org/2015/09/08-shapes-irc
07:48:42 [trackbot]
RRSAgent, make logs rdf-data-shapes
07:48:42 [Zakim]
Zakim has joined #shapes
07:48:44 [trackbot]
Zakim, this will be SHAPES
07:48:44 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
07:48:45 [trackbot]
Meeting: RDF Data Shapes Working Group Teleconference
07:48:45 [trackbot]
Date: 08 September 2015
07:53:16 [hknublau]
hknublau has joined #shapes
07:53:50 [Arnaud]
webex doesn't work
07:54:10 [Arnaud]
we'll use a different teleconference bridge: Passcode: 406-4254 Tel: 888-426-6840/215-861-6239 More access numbers: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=4064254&accessNumber=2158616239
07:55:29 [simonstey]
simonstey has joined #shapes
07:56:27 [Arnaud]
Arnaud has changed the topic to: we'll use a different teleconference bridge: Passcode: 406-4254 Tel: 888-426-6840/215-861-6239 More access numbers: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=4064254&accessNumber=2158616239
07:58:41 [Arnaud]
present+ hknublau
07:58:46 [Arnaud]
present+ Dimitris
07:58:51 [pfps]
pfps has joined #shapes
07:59:07 [Arnaud]
present+ ericp, Arnaud
07:59:20 [iovka]
iovka has joined #shapes
07:59:44 [Arnaud]
beware, check the call-in info: we are using a different teleconference bridge: Passcode: 406-4254 Tel: 888-426-6840/215-861-6239 More access numbers: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=4064254&accessNumber=2158616239
07:59:57 [Arnaud]
present+ iovka
07:59:58 [hsolbrig]
hsolbrig has joined #shapes
08:00:53 [simonstey]
have you joined webex alreadxy?
08:01:05 [Arnaud]
hi simon
08:01:08 [Arnaud]
no webex today
08:01:17 [aryman]
aryman has joined #shapes
08:01:22 [Arnaud]
we are using a different teleconference bridge: Passcode: 406-4254 Tel: 888-426-6840/215-861-6239 More access numbers: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=4064254&accessNumber=2158616239
08:02:00 [simonstey]
is there a way to dial in via voip/sip?
08:02:11 [Arnaud]
I'm afraid not
08:02:19 [pfps]
the access code is not recognized
08:02:22 [simonstey]
oh..
08:02:43 [pfps]
because you need the passcode
08:02:55 [aryman]
hi, the access code works for me
08:02:57 [Arnaud]
pfps, did you try what I just put on irc?
08:03:06 [hknublau]
I am using the Aussie toll-free number via Skype. No idea yet if Skype charges me for that…
08:03:18 [Arnaud]
webex isn't working
08:03:29 [Arnaud]
hknublau, it shouldn't
08:03:34 [aryman]
this worked for me: 406-4254 Tel: 888-426-6840
08:03:36 [hsolbrig]
Skype isn't charging for the US toll free
08:03:45 [Arnaud]
present+ aryman
08:03:51 [pfps]
You need to enter the passcode when it asks for the access code.
08:03:53 [Arnaud]
present+ pfps
08:04:07 [hsolbrig]
present+ hsolbrig
08:04:36 [Arnaud]
simonstey, can you try skype?
08:05:03 [Arnaud]
you should be able to have a toll free number from https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=4064254&accessNumber=2158616239
08:05:08 [Arnaud]
you don't have a phone at all?
08:06:37 [simonstey]
I'm joining via skype
08:06:43 [Arnaud]
sounds good
08:06:49 [pfps]
You need to enter the "passcode" when it asks for the "access code".
08:07:00 [simonstey]
and after that?
08:07:08 [Arnaud]
you should be on
08:07:13 [pfps]
I edited the meeting page to get rid of the webex information.
08:07:27 [simonstey]
can you hear me?
08:07:32 [hknublau]
no
08:07:33 [pfps]
no
08:07:38 [simonstey]
ok mom
08:07:45 [simonstey]
ive joined
08:07:53 [simonstey]
trying to get the mic working
08:07:54 [simonstey]
yes
08:09:51 [simonstey]
skype tells me my mic is working
08:10:14 [simonstey]
;)
08:10:32 [iovka]
scribe: iovka
08:11:31 [iovka]
TOPIC: meeting agenda
08:15:27 [Labra]
Labra has joined #shapes
08:16:10 [kcoyle]
kcoyle has joined #shapes
08:16:44 [iovka]
Arnaud: we should go closer to a first working draft
08:17:19 [iovka]
Arnaud: one way to go is to scale down the document on which we all agree
08:18:38 [iovka]
s/document/document to something/
08:19:23 [hknublau]
lol
08:19:37 [iovka]
pfps: I sent an e-mail with the problems in the document
08:19:57 [iovka]
pfps: the introduction is not a consensus and is misleading for what shacl is
08:20:23 [iovka]
pfps: another issue are technical flaws, terminology issues
08:21:35 [iovka]
pfps: missing a less technical introduction of what shacl is supposed to be
08:22:32 [iovka]
pfps: relationship between shacl and rdfs, recursive shapes
08:23:23 [kcoyle]
q+
08:23:47 [aryman]
aryman has joined #shapes
08:23:52 [aryman]
q+
08:24:02 [ericP]
Arnaud: summarizing pfps
08:24:08 [ericP]
Arnaud: summarizing pfps's issues:
08:24:15 [Arnaud]
ack kcoyle
08:24:46 [iovka]
kcoyle: does not understand what is behind the 3 bullets
08:24:55 [Arnaud]
ack aryman
08:25:36 [iovka]
arthur: the draft is very influenced by holger's implementation
08:25:47 [iovka]
arthur: things are there that have not been discussed by the wg
08:27:22 [iovka]
arthur: holger is making sparql much more essencial for the draft than what the wg agreed on (namely, defining semantics in sparql as much as possible, and extension language)
08:27:42 [iovka]
s/arthur/aryman/
08:28:47 [iovka]
aryman: calling the built-in features "templates" is misleading, templates are supposed to be extnesions
08:29:29 [iovka]
aryman: extension API does not need to be defined in detail, it can be implementation specific
08:29:53 [kcoyle]
+1 to what Arthur says
08:29:59 [hknublau]
q+
08:30:06 [iovka]
aryman: we need a precise description of the syntax and semantics of shacl, and that's the essential thing
08:30:45 [iovka]
Arnaud: resolutions we took regarding sparql are: define the semantics with sparql as much as possible
08:30:52 [iovka]
... use sparql as extension mechanism
08:31:08 [iovka]
... the core does not require implementation in sparql
08:31:12 [Arnaud]
ack hknublau
08:31:41 [iovka]
hknublau: everything aryman said is already in the spec
08:32:05 [aryman]
q+
08:32:09 [iovka]
... very little sparql left, don't understand what aryman is talking about
08:32:49 [Arnaud]
ack aryman
08:34:00 [iovka]
aryman: if hknublau already addressed my comments, then it's fine for me
08:35:02 [iovka]
aryman and hknublau discussing on what is currently in the spec
08:36:29 [iovka]
hknublau explains in details how templates work
08:37:10 [iovka]
aryman: putting the abstract classes for templates makes them a kind of an api
08:38:54 [hknublau]
q+
08:39:15 [iovka]
Arnaud: we could not solve all these issues today, but we can agree on a plan for getting something that is good enough to be published
08:39:17 [hknublau]
q-
08:40:16 [iovka]
pfps: explains what he thinks is the main issue with the spec
08:40:23 [hknublau]
q+
08:40:30 [iovka]
... this is the example in the introduction, which relates classes with shapes
08:41:11 [iovka]
Arnaud: agrees that this example is not appropriate, as it is on a contraversial topic
08:41:27 [Arnaud]
ack hknublau
08:41:56 [pfps]
q+
08:42:02 [iovka]
hknublau: how much longer do we plan to delay this problem ? why not solve it right now
08:42:43 [iovka]
... let's decide whether we delete or not shapeclass, and if the wg decides not to delete it, then why removing the example ?
08:42:59 [pfps]
q- as Arnaud is saying what I was going to say
08:43:03 [pfps]
q-
08:43:15 [iovka]
Arnaud: even if we resolve the issue, and we keep shape class, still this is not the best first and foremost example
08:43:23 [pfps]
a big +1 to Arnaud's comments about not emphasizing shapes as classes
08:43:55 [pfps]
q+
08:43:56 [ericP]
q+ to disagree about class
08:44:07 [aryman]
q+
08:44:10 [Arnaud]
ack pfps
08:44:22 [iovka]
pfps: totally disagree
08:44:25 [Arnaud]
ack ericP
08:44:25 [Zakim]
ericP, you wanted to disagree about class
08:45:00 [iovka]
ericP: totally disagree with holger's assertion that having a class in the leading example is more instructive for people using owl and rdf classes
08:45:06 [pfps]
+1 to eric
08:45:09 [Arnaud]
ack aryman
08:45:50 [iovka]
aryman: the first example should be as simple and useful and possible, to illustrate some key point and one point at a time, and not several points at a time
08:45:50 [hknublau]
q+
08:45:58 [Arnaud]
ack hknublau
08:46:33 [ericP]
ericP: the majority of users of OWL and RDFS classes intend them to defined reusable classes, and this is contrary to the use of shapeClass
08:46:38 [iovka]
hknublau: the most important thing is to publish this document, so I can remove the example if it is necessary
08:47:05 [iovka]
... let's resorve it now
08:47:45 [pfps]
q+
08:47:48 [iovka]
... I would prefer to remove any example, and leave it to a primer
08:48:05 [aryman]
q+
08:48:19 [Arnaud]
ack pfps
08:48:20 [iovka]
Arnaud: specs do have examples
08:50:10 [Arnaud]
ack aryman
08:50:15 [iovka]
pfps: maybe in the final version, there might not be a need for examples. But we have better examples
08:50:24 [hknublau]
q+
08:50:38 [simonstey]
+1 to arthur's comment
08:50:53 [iovka]
aryman: a spec w/o examples is unreadable. for the first publication we need examples, and even for the final. otherwise people won't refer to the spec, but to the primer
08:51:02 [Arnaud]
ack hknublau
08:51:09 [pfps]
my feeling is that the first technical document on SHACL needs a comprehensible introduction to SHACL and that this requires an example, at least for now
08:51:43 [iovka]
hknublau: I can make an introduction similar to what pfps suggested
08:51:52 [kcoyle]
q+
08:52:00 [Arnaud]
ack kcoyle
08:52:29 [ericP]
+1
08:52:43 [iovka]
kcoyle: strongly believe that the current introduction should be removed, and the pfps wording would be used as an introduction
08:53:58 [iovka]
hknublau: the introduction was written to give a high level idea of shacl is, mentioning different features of shacl
08:54:16 [iovka]
kcoyle: asks to pfps to make precise what edit he proposes
08:54:45 [iovka]
pfps: replace 1.1, 1,2, 1.3
08:56:35 [iovka]
kcoyle: we should have a document outline (explains what's in the document) which would be 1.1
08:57:05 [iovka]
kcoyle: it's different from an outline on the specification and the points being addressed
08:57:30 [iovka]
Arnaud: propses that pfps's text is integrated in the current introduction
08:57:53 [iovka]
... I would propose to consider now aryman's concerns
08:58:12 [iovka]
there should be a core of the language that addresses 80% of the use cases
08:58:22 [iovka]
... sparql is an extension
08:58:23 [hknublau]
q+
08:58:43 [aryman]
+1 tp Arnaud's summary of the role of SPARQL
08:58:49 [aryman]
s/tp/to/
08:58:58 [iovka]
TOPIC: discussing the role of sparql
09:00:04 [iovka]
hknublau: sparql could be mentioned in the introduction
09:00:20 [iovka]
... or move it to Secti. 6 (extension)
09:00:40 [iovka]
ericP: agrees with moving sparql to section 6
09:00:44 [iovka]
kcoyle: agrees
09:01:01 [iovka]
Arnaud: the introduction should talk about whole shacl, not only core
09:01:22 [iovka]
kcoyle: still we do not need to explain sparql extension in the introduction, we can simply mention it is an extension mechanism
09:02:09 [iovka]
hknublau: we could have an abstract section before the introduction, and mention there what is in the document
09:04:05 [Arnaud]
Arnaud has joined #shapes
09:04:12 [Arnaud]
q?
09:04:18 [hknublau]
q-
09:04:56 [iovka]
Arnaud: propose to give hknublau a chance to edit the introduction in the sense we propesed, and see what we get
09:05:21 [iovka]
... let's get to pfps's concern that the current document does not describe what shacl is
09:05:35 [iovka]
... how can we solve it, is it an nomenclature issue
09:06:18 [iovka]
pfps: my comments refered to the version I read
09:06:58 [iovka]
I didn't recognize shacl
09:07:25 [iovka]
s/I/pfps: I/
09:07:34 [iovka]
Arnaud: can you give an example ?
09:07:54 [iovka]
pfps: shacl is presented as an rdf vocabulary. it is a language, not a vocabulary
09:08:25 [iovka]
... shacl does not describe graph structures, this is not its purpose
09:08:42 [hknublau]
q+
09:08:46 [iovka]
... shacl is a constraint language, it is not to describe to graph structures, but to validate rdf graphs
09:09:03 [iovka]
... i turns out that it has to describe graph strucutres, but it not its purpose
09:09:18 [iovka]
pfps: towards the document "shacl mandates ..."
09:09:43 [iovka]
... it checks constraints, it does not mandate
09:10:50 [iovka]
... regarding the relationshipe between shapes and constraints, didn't understand what the wording wanted to say, I didn't understand how to read it (referring to the version form August 10)
09:10:59 [iovka]
... don't know how it was changed
09:11:33 [iovka]
Arnaud: hknublau is making edits to reflect our comments, so we can hope the wording goes in your direction
09:11:59 [simonstey]
there is a revision history in the beginning of the document
09:12:37 [iovka]
Arnaud: so the question is : how do we collectively descibe what shacl is, so that we know what to write in the introduction and a first-time reader gets the right idea of shacl
09:12:38 [ericP]
q+ to disagree with one of pfps's points: whether shacl "describes" structure
09:13:03 [iovka]
Arnaud: maybe the further sections are more controversal, the introduction should give the right idea
09:13:21 [iovka]
... validation is not the primary purpose of all users
09:13:44 [iovka]
... e.g. people from the linked data platforms want to describe the data
09:14:15 [aryman]
q+
09:14:28 [iovka]
... are there other interests ?
09:14:44 [iovka]
pfps: who wants shacl for primarily describe structures ?
09:15:43 [iovka]
ericP: me. first you describe the data, then this description can be used for validation. Cites the introductory sentence for XMLSchema
09:16:26 [iovka]
... shacl is a language for describing the graph structure, and a validation mechanism for checking whether a graph satisfies the structure
09:16:51 [iovka]
kcoyle: is not convinced that "structure" is the best wording
09:17:13 [iovka]
hknublau: definetely, describing the sttructure is important
09:17:19 [pfps]
q+
09:17:32 [kcoyle]
q+
09:18:14 [ericP]
ack next
09:18:15 [ericP]
ack next
09:18:16 [Zakim]
ericP, you wanted to disagree with one of pfps's points: whether shacl "describes" structure
09:18:17 [ericP]
ack next
09:18:31 [Arnaud_]
Arnaud_ has joined #shapes
09:18:53 [pfps]
I agree with Eric that conflating "describing graph structures" and "modelling" is a stretch
09:18:57 [Arnaud_]
q?
09:18:59 [pfps]
q-
09:19:06 [iovka]
aryman: oslc is a description language for rdf data
09:19:32 [iovka]
... many of our users are not familiar with rdf and want description of the data
09:19:48 [pfps]
q+
09:20:17 [Arnaud_]
ack kcoyle
09:20:29 [iovka]
... also having a pragmatic way of validating rdf data
09:21:38 [Arnaud_]
ack pfps
09:21:56 [iovka]
kcoyle: our primary need is to describe data. we do not separate validation and description. the word 'validation' is hard to find in the current introduction. if people do not need to validate, then they would not use shacl
09:22:20 [iovka]
pfps: agrees that one does not use shacl for only description. The design of shacl was oriented towards valdiation.
09:22:35 [hsolbrig]
+1 on description is not modeling
09:22:36 [iovka]
... description is not modelling4
09:22:50 [iovka]
Arnaud: we can talk about description, validation, constraints
09:22:56 [iovka]
... no modelling
09:23:04 [iovka]
hknublau: agree with that
09:23:27 [pfps]
q+
09:23:34 [iovka]
Arnaud: would that address the primary concerns about the current draft and its introduction of what shacl is
09:23:34 [Arnaud]
ack pfps
09:23:52 [iovka]
pfps: it appears so
09:24:12 [iovka]
... there is also the issue for the relationship between shacl and rdfs
09:25:25 [iovka]
pfps: it's also about terminology. the document uses the words classes, rdf:type, rdfs:subClass etc, but not in a way RDFS does
09:25:46 [hknublau]
q+
09:25:51 [iovka]
... these uses are not conform with RDFS, so I fear that people would misunderstand shacl
09:26:39 [iovka]
... at the very minimum, we need a disclaimer. explain to people that shacl does not use RDFS as it is
09:27:01 [Arnaud]
ack hknublau
09:27:07 [simonstey]
to what extend is the current spec using subclassof wrong wrt to the official spec?
09:27:12 [iovka]
... misunderstanding of shacl would discourage people from using it
09:28:01 [pfps]
q+
09:28:03 [iovka]
hknublau: pfps, maybe you can suggest a paragraph that explains to RDFS-aware people woh to read the document in order to avoid the misunderstanding ?
09:28:30 [aryman]
q+
09:28:58 [iovka]
... not sure that our understanding is so different
09:30:00 [iovka]
pfps: very different. the usage of subclass is different
09:30:12 [iovka]
... also, does not use domain and range from RDFS
09:30:29 [iovka]
... also, no subProperty in shacl
09:31:53 [Arnaud_]
Arnaud_ has joined #shapes
09:31:55 [iovka]
hknublau: we had an agreement that if one wants inference, it should be done on the graph level, by turning inference on
09:32:06 [Arnaud_]
q?
09:32:11 [Arnaud_]
ack pfps
09:33:06 [Arnaud_]
ack aryman
09:33:08 [iovka]
pfps: this is not the unique differences. the document should state it explicitly how shacl uses the rdfs vocabulary
09:33:21 [iovka]
Arnaud: pfps, can you write this explanation
09:33:25 [iovka]
pfps: agrees
09:34:07 [iovka]
aryman: from a pragmatic point of view, ce nannot rely on entailment being turned on or turned off
09:34:16 [hknublau]
http://w3c.github.io/data-shapes/shacl/#entailment
09:34:28 [iovka]
... we could have an entailment property, that specifies whether entailment is supposed to be used
09:35:07 [iovka]
... when we say that A is subclass of B, we simply require a subclass triple, we are not interested to know whether it is explicit or obtained by inference
09:35:41 [iovka]
... sublcass can be also implemented as a transitive closure
09:35:53 [pfps]
q+
09:35:54 [iovka]
... which is a pragmatic solution
09:36:09 [Arnaud_]
ack pfps
09:36:12 [hknublau]
+1 to arthur
09:36:12 [iovka]
... for me this would describe our relation to rdfs
09:36:48 [iovka]
pfps: agree with aryman, except can't seay we both require explicit rdfs:subclass links, and we compute a transitive closure
09:37:58 [Arnaud_]
q?
09:38:26 [Dimitris]
+q
09:38:56 [iovka]
pfps: rdfs:subclass not being uniformly applied
09:39:18 [iovka]
aryman: you can be pragmatic, explain it, and see how people from RDFS community react
09:39:23 [Arnaud_]
ack Dimitris
09:39:30 [iovka]
Arnaud: let's peter make a first draft, and we see how it goes
09:40:21 [iovka]
Dimitris: scribe didn't get the point because of bad phone connexion
09:41:07 [Dimitris]
we should also define how rdfs reasoning is applied inside the shacl graph for the shape / template definition
09:41:22 [iovka]
Arnaud: we have a general plan: change teh introduction using peter's text, add a section on relatioship with rdfs, and remove the reference to classes in the leading example
09:41:37 [iovka]
... peter, is that ok for you ?
09:42:26 [iovka]
pfps: other things are missing, the document does not talk about recursive shapes, the relationship with sparql is incorrect
09:42:47 [iovka]
... these are very serious technical problems
09:42:57 [iovka]
Arnaud: we've got issues for most of these
09:43:16 [iovka]
... if not, raise an issue
09:43:47 [iovka]
pfps: enumerates some technical problems, e.g. the documents talks about 'matching' and 'typing' and these are not defined. shall I raise an issue for that ?
09:44:07 [iovka]
Arnaud: agrees this is a serious issue, the document suffers from consistency
09:44:27 [iovka]
pfps: also missing how do you start a validation
09:45:09 [hknublau]
+q to say that most of this is already fixed
09:46:29 [iovka]
Arnaud: wonders how deep we should go in the spec. for instance, should we describe the api in the spec, or how errors are reported ?
09:46:33 [Arnaud_]
ack hknublau
09:46:33 [Zakim]
hknublau, you wanted to say that most of this is already fixed
09:46:53 [iovka]
hknublau: I believe that pfps's issues and yours have been addressed now
09:47:19 [iovka]
... I'm trying to improve it, but it will never be perfect
09:47:42 [pfps]
q+
09:47:44 [iovka]
... difficult situation to keep the document consistent whereas things are changing so often
09:48:01 [iovka]
... I'm waiting for resolutions before editing the document
09:48:11 [pfps]
q-
09:49:02 [aryman]
q+
09:49:48 [pfps]
q+
09:50:01 [Arnaud]
Arnaud has joined #shapes
09:50:04 [Arnaud]
ack aryman
09:50:16 [iovka]
aryman: there should be a description of what input and output is
09:50:41 [iovka]
... but not going into so much details as hknublau
09:50:55 [simonstey]
+q
09:51:18 [iovka]
... we should have the relationship between the input and the output
09:51:38 [iovka]
hknublau: trying to do that, but we need to describe it with sparql queries
09:52:11 [Arnaud]
ack pfps
09:52:22 [pfps]
q-
09:52:29 [Arnaud]
ack simonstey
09:53:00 [iovka]
simonstey: also think that section 10 is not needed in the main document, all the operations are not referenced anywhere else in the document
09:53:52 [iovka]
... agree that we should remove that from the normative document
09:54:20 [iovka]
Arnaud: maybe we can agree to move it to another document
09:54:43 [iovka]
... let's try to address some of the aryman's concerns
09:54:55 [iovka]
... for instance the role of sparql in the document and for shacl
09:55:22 [iovka]
... for instance, notions of template definition and execution engine which is sparql
09:55:38 [iovka]
... shouldn't 'engine' be replaced by 'extension' ?
09:55:58 [aryman]
q+
09:56:12 [iovka]
hknublau: asks for a clarification
09:57:06 [iovka]
Arnaud: for instance title of sect 13: Sparql execution to be replaced by sparql extension
09:57:15 [iovka]
... templates are part of the extension mechanism.
09:57:21 [iovka]
... we have the core and the extensions
09:57:38 [iovka]
... two kinds of extensions, one of which is templates
09:57:51 [aryman]
can't hear holger
09:58:08 [Arnaud]
ack aryman
09:59:06 [simonstey]
the core elements are also defined in terms of templates (which are defined using sparql queries)
09:59:12 [iovka]
aryman: agrees with Arnaud. refers to an e-mail in which hknublau does not agree that sparql is just an extension language
09:59:36 [pfps]
I was going to make the point that the other document has a definition of recursive shapes.
10:01:12 [iovka]
hknublau: sparql has a special role because we are defining the semantics of shacl using sparql
10:01:16 [iovka]
... so that it is special
10:01:22 [pfps]
The current document gives the impression that SHACL can be implemented in SPARQL, which is not currently correct.
10:01:25 [iovka]
Arnaud: want to clarify this
10:01:29 [iovka]
... sparql has two roles
10:01:35 [iovka]
... one is defining the semantics
10:01:42 [iovka]
... the other is an extension mechanism
10:01:53 [iovka]
... I do not think that sparql should be presented as the foundation of the core
10:02:00 [pfps]
q+
10:02:18 [Arnaud]
ack pfps
10:02:23 [iovka]
... I know that in your implementation, holger, you do use it as the foundation of the core. But this is your implementation choice, and we should not impose this to everybody
10:02:26 [simonstey]
wouldn't we then have to decouple the .ttl from the spec? since it uses sparql to define those constructs
10:02:47 [iovka]
pfps: scribe didn't hear the question of pfps
10:03:11 [iovka]
aryman: we are using sparql as a precise formalism, but not an execution mechanism
10:04:09 [pfps]
my comment was that SPARQL is inadequate for the definition of SHACL
10:04:11 [Arnaud_]
Arnaud_ has joined #shapes
10:04:14 [Arnaud_]
q?
10:04:36 [iovka]
hknublau: doesn't understand the issue with sparql, it is not mentioned before section ??
10:04:43 [pfps]
Arthur noted that large chunks of SHACL (i.e. almost all of SHACL) can be formalized as SPARQL, and I agreed.
10:05:15 [iovka]
Arnaud: the proposal is just to rename 'execution' to 'extension'
10:05:31 [iovka]
hknublau: I do not understand why I should do that
10:05:48 [iovka]
Arnaud: because it gives the impression that sparql is the foundation
10:06:01 [iovka]
hknublau: does not agree with this statement
10:06:14 [iovka]
kcoyle: you are saying it in Sect. 13
10:06:30 [simonstey]
then make it a subsection instead of a section
10:07:17 [simonstey]
\section(extension/execution languages) -> \subsection{SPARQL-based ...}
10:07:24 [aryman]
q+
10:07:33 [iovka]
Arnaud: insists that we only ask to rename execution by evaluation, because now this gives the impression that it is the foundation
10:07:42 [iovka]
kcoyle: maybe it should be a seperate document
10:07:44 [iovka]
+q
10:08:01 [Arnaud_]
s/evaluation/extension/
10:08:17 [Arnaud_]
ack aryman
10:08:21 [iovka]
hknublau: how can we have a self contained document if we do not give the semantics in sparql
10:08:39 [iovka]
kcoyle: the details of any implementation do not belong to the spec
10:08:41 [iovka]
-q
10:08:51 [iovka]
+q
10:09:01 [kcoyle]
+1 to Arthur
10:09:24 [iovka]
aryman: sparql should be used to specify the semantics independently on any implementation
10:09:42 [iovka]
-q wanted to say basically what aryman says
10:09:46 [ericP-via-http]
ericP-via-http has joined #shapes
10:09:52 [iovka]
-q
10:10:00 [Arnaud_]
ack iovka
10:10:25 [ericP]
iovka: you can specify without executing it. a declarative execution doesn't need an "execution"
10:10:53 [iovka]
s/declarative execution/declarative specification/
10:11:03 [iovka]
Arnaud: maybe a solution is to move it out
10:11:20 [iovka]
... and go forward to a publishable working draft
10:11:34 [iovka]
hknublau: asks whether peter agrees
10:11:58 [iovka]
pfps: it would be a shape to remove from the document the connexion between shacl and sparql
10:12:17 [pfps]
s/shape/shame/
10:12:19 [iovka]
... but I agree that giving the impression that the execution mechanism of shacl is sparql is problematic
10:12:54 [iovka]
hknublau: asks that somebody points him the precise sentences to be removed
10:13:47 [iovka]
Arnaud: the consensus seems to be to move this section to a separate document
10:14:04 [pfps]
I think that there needs to be some discussion of the formal basis of SHACL in the document.
10:14:53 [iovka]
... we should edit the changes that we already discussed, review the resulting document, and see whether we get closer to a public working draft
10:15:13 [aryman]
q+
10:15:26 [Arnaud_]
ack aryman
10:16:03 [iovka]
aryman: in some specs, you can have separate document for the formal semantics
10:16:12 [iovka]
... in order to keep the spec readable from the largest part
10:16:26 [iovka]
... the semantics document is read by people who are making an implementation
10:16:45 [iovka]
... i think we should keep the extension mechanism in the main document, and sparql is the preferred extension language
10:17:14 [iovka]
Arnaud: we stop for a lunch break, the topic is apparently not closed
10:17:27 [hsolbrig]
No sunrise here yet
10:53:44 [hknublau]
Yes I used Skype. The Australian toll-free number :)
10:53:56 [simonstey]
try 0800-000-1018 for germany
11:01:17 [aryman]
aryman has joined #shapes
11:05:28 [simonstey]
* and loud
11:06:41 [hsolbrig]
Isn't this the sort of thing they play to prisoners to get them to confess?
11:07:04 [aryman]
just in "A Clockwork Orange"
11:07:19 [hsolbrig]
I want to strangle the happy "Your conference will begin momentarily..." woman
11:07:55 [simonstey]
especially when she repeats herself 3-4 times within a few seconds
11:08:44 [hsolbrig]
And strange warbly distortions, like she isn't quite sane
11:08:59 [Arnaud]
Arnaud has joined #shapes
11:09:26 [simonstey]
haha
11:09:42 [hsolbrig]
Welcome Arnaud. The conference woman has worked us into a killing frenzy
11:09:48 [aryman]
@Arnaud, please tell us when to call back in
11:10:05 [kcoyle]
kcoyle has joined #shapes
11:10:05 [hsolbrig]
All that music and then the happy woman just hangs up!
11:10:08 [Arnaud]
now
11:10:25 [Arnaud]
sorry guys, we're a bit behind
11:10:25 [eric-via-http]
eric-via-http has joined #shapes
11:10:27 [ericP]
iovka: you can specify without executing it. a declarative execution doesn't need an "execution"
11:10:37 [ericP]
s/iovka: you can specify without executing it. a declarative execution doesn't need an "execution"//
11:10:42 [kcoyle]
scribenick: kcoyle
11:10:45 [Arnaud]
service wasn't quite as fast as iovka led us to believe
11:12:00 [pfps]
present+ pfps
11:12:01 [simonstey]
present+ simonstey
11:12:09 [Dimitris]
present+ dimitris
11:12:10 [hsolbrig]
present+ hsolbrig
11:12:27 [hknublau]
present+ hknublau
11:12:35 [Labra]
Labra has joined #shapes
11:12:49 [kcoyle]
TOPIC: Plan for main draft - continues
11:13:05 [kcoyle]
Arnaud: Can we have additional editors on the spec?
11:13:41 [kcoyle]
arthur
11:14:10 [kcoyle]
aryman: Yes, I could devote some time to it; esp. if we split off semantics from rest of document
11:14:23 [kcoyle]
... could do pure editorial work
11:15:23 [kcoyle]
Arnaud: should be able to make use of github for changes; fork and pull
11:16:02 [kcoyle]
Arnaud: Idea of profiles in the spec; way to define a set of templates
11:16:13 [kcoyle]
... but doens't seem to be defined in spec
11:16:41 [kcoyle]
hknublau: No, not in spec; informal; could be used to check if a file fits a profile
11:17:20 [kcoyle]
... could be used by compact syntax to say what it addresses
11:18:07 [kcoyle]
... you don't specify anything, just what features you support
11:18:33 [aryman]
q+
11:18:58 [pfps]
q+
11:19:35 [Arnaud]
ack aryman
11:20:21 [kcoyle]
aryman: shouldn't subset core; not clear what is meant by profile
11:20:51 [Arnaud]
ack pfps
11:20:54 [kcoyle]
hknublau: reading too much; nothing depends on them; could be dropped; just says what you support and do not
11:21:42 [kcoyle]
pfps: profiles can be useful, but this mechanism is underpowered. can you use this to say you don't use recursive shapes?
11:21:43 [kcoyle]
hk
11:22:40 [kcoyle]
pfps: all this says is: I have following templates. excludes useful situations
11:23:24 [kcoyle]
hknublau: if we want to take this further, we could say use profiles to point to constraints , e.g. any shape could not mention same property twice
11:23:58 [kcoyle]
pfps: you could exclude recursive shapes by saying no data shapes
11:24:05 [iovka]
iovka has joined #shapes
11:25:00 [kcoyle]
Arnaud: may have to decide if it is useful at all, or if it is worth doing more work to make it useful; raises questions, has few answers
11:25:15 [Arnaud_]
Arnaud_ has joined #shapes
11:25:25 [pfps]
if SHACL had a constraint that forbid data loops, then it might be able to use it to create a profile that excluded recursive shapes
11:25:34 [aryman]
+1 for deferring Profiles
11:25:55 [pfps]
+1 for deferring profiles
11:26:08 [pfps]
Note that this is not deferring profiles, just deferring the section on profiles
11:26:21 [simonstey]
+1 to peter's addition
11:26:21 [Dimitris]
+1
11:27:16 [kcoyle]
pfps: core is a profile; section 9 is a particular mechanism
11:27:24 [kcoyle]
Arnaud: agreed: remove section 9 for now
11:27:58 [kcoyle]
Arnaud: return to template conversation: Holger says if removed the rest of document will not work
11:29:39 [kcoyle]
hknublau: wishes to make sure that sparql is part of the standard; group has received agreement on many things
11:30:12 [kcoyle]
... if stuff is in a separate document someone could say: let's get rid of that document
11:30:34 [kcoyle]
Arnaud_: being in a different document shouldn't matter; the content matters
11:31:39 [kcoyle]
...extension is a template - the template should be the same regardless of the execution mechansim
11:32:34 [kcoyle]
hknublau: yes, that's the case, templates are an envelope; template mechanism should remain in the main document
11:32:50 [pfps]
currently the document states " Each constraint needs to be backed by at least one executable body in SPARQL". This is a strong statement about the role of SPARQL in SHACL.
11:33:10 [kcoyle]
Arnaud_: so, templates work without section 13
11:33:35 [kcoyle]
hknublau: yes, agrees; sparql document will be short and could be published at the same time
11:33:58 [simonstey]
@pfps if we are dropping this statement we shouldn't aim to publish the .ttl as normative document, right?
11:33:58 [pfps]
q+
11:34:03 [Arnaud_]
ack pfps
11:35:22 [kcoyle]
pfps: current doc does not match resolutions of the working group "should be specified in sparql as much as possible' & 'sparql is a / the execution language'
11:36:01 [kcoyle]
... should stay or else is misleading; possibly section 13 should survive in a modified form but without the parts people object to
11:36:40 [kcoyle]
... renaming section 13, as per Arnaud, would go a long way
11:36:44 [simonstey]
+q
11:37:12 [kcoyle]
aryman: what is section 13? semantics or execution
11:37:25 [kcoyle]
pfps: it should primarily be about the meaning of SHACL
11:37:29 [simonstey]
-q
11:37:33 [Arnaud_]
ack simonstey
11:39:15 [kcoyle]
simonstey: problem sh:sparql property serves two functions: both defines SHACL functions and is also an extension
11:39:36 [aryman]
q+
11:40:18 [kcoyle]
aryman: If section 13 is about the semantics then the sparql defintion should be in the document not the turtle file
11:40:45 [kcoyle]
Arnaud_: topic: what is in the turtle file and what is its relation to the shacl draft?
11:41:55 [kcoyle]
hknublau: if you instantiate shacl you need a schema; and the ttl file provides that schema, can validate against it
11:42:54 [kcoyle]
...can be used at run time; means no difference between core and template execution
11:43:04 [kcoyle]
... shacl is written using shacl
11:43:42 [kcoyle]
pfps: there's no file that carries any evaluation semantics for OWL
11:44:31 [kcoyle]
aryman: we are confusing the semantics of shacl with the implementation; vocab document should be rdfs of shacl as a vocabulary, without the sparql
11:45:17 [kcoyle]
... that's bad because you can't fully describe the semantics in sparql, so there's no place to specify those; doesn't provide what is needed for a non-sparql implementation
11:45:47 [Arnaud]
Arnaud has joined #shapes
11:46:18 [kcoyle]
... the turtle doc is normative, so shouldn't contain implementation; this combines semantics with implementation
11:47:16 [Arnaud]
q?
11:47:21 [Arnaud]
ack aryman
11:49:04 [kcoyle]
... difference between describing implement and describing semantics; latter should not require sparql or java or any particular language
11:51:32 [ericP]
q+
11:51:37 [pfps]
q+ to ask where the definition of the SPARQL extension function is
11:51:48 [kcoyle]
Arnaud: there are other specs that rely on sparql, e.g. graph store protocol. then people believe that sparql is required and miss that they can implement it in another language
11:52:19 [kcoyle]
... convenience is there, but also mis-understanding
11:52:32 [kcoyle]
.... so we need to find a mid-point
11:52:36 [Arnaud]
ack ericP
11:53:23 [kcoyle]
ericP: the sparql graph store protocol: its behavior is exactly what sparql does so that was easy and natural;perfect alignment between gsp and sparql
11:54:01 [kcoyle]
... no composition within that language - no combining of gsp functions; was much easier to define than shacl
11:54:25 [Arnaud]
ack pfps
11:54:25 [Zakim]
pfps, you wanted to ask where the definition of the SPARQL extension function is
11:55:39 [kcoyle]
pfps: definition of sh:hasShape -- not good; description there doesn't make possible implemention of function. Other functions around it are not similar. This one requires work.
11:55:58 [Arnaud]
http://w3c.github.io/data-shapes/shacl-ref/#hasShape
11:56:05 [kcoyle]
...problem therefore with description of relationship between shacl and sparql.
11:56:39 [kcoyle]
hknublau: this is independent of sparql, which is why it is here
11:57:05 [kcoyle]
... it's in validate node against shape
11:57:25 [Arnaud]
https://w3c.github.io/data-shapes/shacl/#operation-validateNodeAgainstShape
11:58:59 [kcoyle]
pfps: sh:hasShape is needed to handle recursive shapes, but is used to handle all shape embeddings
11:59:20 [pfps]
I don't see that 10.2 has anything to do with the sh:hasShape
11:59:26 [kcoyle]
... 10.2 validatenodeagainstshape is not about that
12:00:38 [kcoyle]
hknublau: 10.2 is independent from sparql
12:01:51 [Arnaud]
q?
12:03:27 [kcoyle]
pfps: the information isn't there; Holger agrees; it's an issue (issue-22)
12:03:37 [Arnaud]
https://w3c.github.io/data-shapes/shacl/#AbstractValueShapePropertyConstraint
12:04:44 [kcoyle]
aryman: operations described in section 10 do not expose the context - may reflect your use of Jena
12:05:45 [kcoyle]
hknublau: hasShape needs to be specified in main doc; but included in SPARQL document
12:07:34 [simonstey]
"Suggested redesign of Operations section"
12:09:03 [kcoyle]
Arnaud: review must also include ttl or its transformation
12:09:57 [pfps]
q+ to talk about implementation details in http://w3c.github.io/data-shapes/shacl-ref/
12:10:07 [Arnaud]
ack pfps
12:10:07 [Zakim]
pfps, you wanted to talk about implementation details in http://w3c.github.io/data-shapes/shacl-ref/
12:11:01 [kcoyle]
pfps: sympathize with arthur's comments - there are many implmentation details in the turtle document; that are unrelated to the work group's view of shacl
12:11:27 [kcoyle]
... that's not necessarily bad as long as there is a good description of what needs to be mirrored (?) or what doesn't
12:11:46 [kcoyle]
... danger is that specification of shacl includes every feature in this document
12:13:39 [aryman]
q+
12:15:16 [kcoyle]
hknublau: abstract classes are not used directly, but are part of the language
12:16:19 [Arnaud]
q?
12:17:58 [Arnaud]
ack aryman
12:19:02 [kcoyle]
aryman: the vocab doc exposes a lot of terms; including that templates can be inherited; the build-in constraints are implemented are templates and are exposed in the vocab
12:19:36 [kcoyle]
... thus they can be the subject of inheritance; this makes a difference for people creating implementations in other languages
12:20:08 [kcoyle]
hknublau: inheritance is additive
12:20:37 [kcoyle]
aryman: implementations have to support this - and it defines what makes for a valid implementation
12:20:51 [kcoyle]
... what are the benefits? we haven't discussed this as a group
12:21:53 [kcoyle]
hknublau: early version had sh:private so people could use private classes; was rejected; exposure of abstract functions necessary for those implementing in another language
12:22:01 [kcoyle]
... needs a stable UIR
12:22:37 [kcoyle]
s/UIR/URI
12:23:16 [kcoyle]
Arnaud: vocab doc should be normative reference in main spec
12:23:50 [kcoyle]
... to be compliant with shacl i have to implement the vocabulary
12:24:06 [pfps]
q+ to say that it is possible to write the first document so that the second does not have to be normative
12:24:47 [simonstey]
it's the "textual" representation of the .ttl file
12:24:59 [Arnaud]
ack pfps
12:24:59 [Zakim]
pfps, you wanted to say that it is possible to write the first document so that the second does not have to be normative
12:25:36 [aryman_]
aryman_ has joined #shapes
12:25:50 [aryman_]
http://w3c.github.io/data-shapes/shacl/
12:26:07 [aryman_]
http://w3c.github.io/data-shapes/shacl-ref/
12:26:39 [kcoyle]
pfps: it would be possible to write the shacl spec in a way that does not require the vocabulary ref to be normative. - english wording in former would need to be precise
12:27:16 [kcoyle]
.... for the core vocabulary there was a sparql extension = sparql as much as possible
12:28:17 [aryman_]
q+
12:28:27 [pfps]
q+
12:28:33 [Arnaud]
ack aryman
12:29:29 [kcoyle]
aryman_: this reflect holger's work on the spec, which is based on his implementation. many people do not have sparql end points. so what is in that file is not going to be useful.
12:29:46 [kcoyle]
hknublau: just attach to the templates
12:30:49 [kcoyle]
aryman_: focus on the language, not try to make life easier for others
12:31:15 [Arnaud]
ack pfps
12:31:24 [kcoyle]
pfps: agrees with arthur
12:32:21 [simonstey]
+q
12:32:47 [Arnaud]
ack simonstey
12:34:18 [kcoyle]
simonstey: need to untangle the ttl file from the normative part; use sparql snippets to define semantics in regular doc. ; don't publish ttl as normative reference
12:35:17 [pfps]
q+
12:35:25 [Arnaud]
ack pfps
12:36:13 [kcoyle]
pfps: a reference implementation is valuable; shows what can be done; putting details of implementation in the spec is a bad idea because it prevents improvement
12:36:39 [kcoyle]
... if ttle had only the things to implement shacl it could be a normative ref; but has problematic aspects
12:37:06 [kcoyle]
s/ttle/ttl
12:37:21 [Arnaud]
PROPOSED: fix the spec so that it doesn't depend on shacl-ref, adding SPARQL snippets to the spec where possible and english language as appropriate
12:37:44 [pfps]
q+
12:37:55 [Arnaud]
ack pfps
12:38:27 [aryman_]
q+
12:38:35 [kcoyle]
pfps: may only be possible for first half; the extension mechanism may have an intertwining with some aspects of an implementation
12:38:45 [Arnaud]
ack aryman_
12:39:33 [kcoyle]
aryman_: when we talk about a language extension, we have to fully define the language bindings - it may be necessary to define hasShape, but that belongs to the binding
12:39:34 [Arnaud]
PROPOSED: fix the spec so that the Core doesn't depend on shacl-ref, adding definitions in english along with SPARQL snippets where possible
12:40:00 [aryman_]
+1
12:40:02 [Labra]
+1
12:40:05 [kcoyle]
+1
12:40:06 [ericP]
+1
12:40:09 [iovka]
+1
12:40:10 [hsolbrig]
+1
12:40:18 [pfps]
+1
12:40:20 [pfps]
q+
12:40:25 [simonstey]
+0.5
12:40:48 [Dimitris]
+0.5
12:40:56 [Arnaud]
ack pfps
12:42:06 [TallTed]
TallTed has joined #shapes
12:42:22 [kcoyle]
pfps: earlier versions had snippets; but not the group sees the consequence of that;
12:43:35 [pfps]
I'm not sure whether this change should happen before or after FPWD publication
12:43:37 [Arnaud]
s/not/now/
12:44:18 [pfps]
??
12:44:46 [pfps]
q+
12:45:09 [hknublau]
-1
12:45:11 [hsolbrig]
wow -- a really soothing dishwasher
12:45:20 [Arnaud]
ack pfps
12:47:59 [pfps]
I did agree with Holger here. This is a big issue, with many technical ramifications. However, Holger is misrepresenting the proposal, and in a very serious matter.
12:49:15 [Arnaud]
RESOLVED: fix the spec so that the Core doesn't depend on shacl-ref, adding definitions in english along with SPARQL snippets where possible
12:50:58 [pfps]
ISSUE-23
12:50:58 [trackbot]
ISSUE-23 -- Shapes, classes and punning -- open
12:50:58 [trackbot]
http://www.w3.org/2014/data-shapes/track/issues/23
12:51:58 [pfps]
I also eradicated punning from the title and description
12:53:09 [Arnaud]
https://w3c.github.io/data-shapes/shacl/#scopeClass
12:54:24 [kcoyle]
Arnaud: shapes and classes can be separate or a class can be a shape
12:54:50 [pfps]
q+
12:54:57 [Arnaud]
ack pfps
12:55:52 [kcoyle]
pfps: shape as class is harmful; it will be used to muscle in another modeling language that is incompatible with RDFS
12:56:04 [kcoyle]
... should not create a modeling language
12:56:11 [ericP]
q+
12:56:26 [aryman_]
q+
12:56:58 [kcoyle]
... ref to ttl file that uses this to use shacl as modeling language
12:57:59 [simonstey]
maybe we should clarify what does a language actually make a modeling language
12:58:18 [Arnaud]
ack ericP
12:59:01 [hknublau]
q+
12:59:24 [kcoyle]
ericP: primary use of rdf is to describe objects with the intent that they get re-used; people frequently use classes in diff. contexts;
13:00:28 [kcoyle]
... attaching the constraints to a class is nuanced to context; some classes are "record" classes where class is structure, and those tend not to be used with constraints
13:00:53 [kcoyle]
... the danger of using classes of shapes matters for the semantic web and data exchange
13:01:46 [kcoyle]
... should only connect shape and class for certain kinds of uses of the class, and what that means for different contexts, and when it is useful
13:02:11 [kcoyle]
... needs to be made clearly in an rdf triple; and make sure no one will re-use this class with different constraints
13:02:43 [Arnaud]
ack aryman_
13:03:43 [kcoyle]
aryman_: this is syntactic sure for something that is core to shacl; can scope a shape to certain type arcs
13:04:06 [Arnaud]
ack hknublau
13:04:25 [aryman_]
holger is breaking up
13:05:47 [kcoyle]
hknublau: very common to have instances of a class and a shape; shapeClass removes two triples; template classes are like eric's record classes
13:05:47 [Dimitris]
+q
13:06:57 [Arnaud]
ack Dimitris
13:07:46 [kcoyle]
Dimitris: preferable to have the shortcut, but define class only within the shacl spec
13:08:01 [pfps]
I'm not arguing against classes as the scope of shapes. Class scopes are valuable in two ways: 1/ they can be used with an external model to provide local constraints 2/ they can be used in a model to provide constraints that should be used by all consumers of a class. If one is building a model, the one should use a modelling language, like RDFS, and not SHACL alone.
13:09:01 [kcoyle]
... assume that rdfs class is defined elsewhere, on the net;
13:09:07 [aryman_]
note that if you have a triple X rdf:type Y then Y is inferred to by a Class
13:09:16 [aryman_]
s /by/be/
13:09:40 [aryman_]
q+
13:10:34 [aryman_]
see http://www.w3.org/TR/rdf-schema/#ch_type
13:10:52 [Arnaud]
ack aryman_
13:10:59 [Dimitris]
see the fist part of this email https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015May/0025.html
13:11:14 [kcoyle]
aryman_: if you use rdf:type then the object is a class
13:12:38 [Dimitris]
ex:ClassA a rdfs:Class, sh:ClassShape .
13:13:04 [iovka]
iovka has joined #shapes
13:13:23 [Dimitris]
ex:ClassA a sh:ClassShape . when the class definition is defined externaly
13:14:16 [ericP]
kcoyle: can you say what the difference is between 1 and 2?
13:14:37 [ericP]
Dimitris: 1 when you wnat shapes and classes i the same doc
13:14:44 [ericP]
... 2 when you want them in different docs
13:14:56 [ericP]
kcoyle: but the meaning is the same, but with fewer triples
13:15:18 [ericP]
Dimitris: yes but i'm not adding the rdfs class in the triple
13:15:24 [simonstey]
2. is actually sh:ShapeClass
13:15:44 [ericP]
scribenick ericP
13:16:03 [ericP]
kcoyle: i don't understand why we'd go through this to save triples if the end meaning is the same
13:16:34 [Arnaud]
q?
13:16:47 [ericP]
... i had the impression that one of the issues is whether this declaration of the shape as a class leaks into the web and, to ericP's point, affects with the interaction of your data with the larger world
13:17:02 [ericP]
Dimitris: no one had to specify it manually
13:17:19 [ericP]
s/no one had/no one has/
13:17:30 [ericP]
kcoyle: matter of counting triples
13:17:50 [ericP]
Arnaud: we need to differentiate between what we allow and what we think is the best thing to do
13:18:17 [ericP]
... we have disagreement on what's best so we have to allow people to shoot themselves in the foot if they want to
13:18:32 [ericP]
... in the first doc, everything depended on the class.
13:18:46 [ericP]
... the current doc allows both views
13:19:06 [ericP]
... in order to address concearns, we should not make this a prominent feature
13:19:23 [ericP]
... don't put it in the top because that's starting on the wrong foot
13:19:28 [hknublau]
+1
13:19:38 [pfps]
q+
13:19:40 [ericP]
... and maybe write a note about the unintended consequences
13:19:50 [hsolbrig]
q+
13:19:56 [hknublau]
These consequences already happen with sh:scopeClass.
13:20:03 [Arnaud]
ack pfps
13:20:04 [ericP]
... let's allow poeple to do what they want
13:20:30 [ericP]
pfps: i'm unconvinced by that argument because one can get the same effect by adding in the extra node and triples
13:20:46 [ericP]
... if you want to do this thing which is problematic, you can still do it.
13:21:06 [ericP]
... all you have to do is add one triple
13:21:26 [pfps]
If you want shapes as classes without any support for SHACL all you need is a sh:classScope triple from the class to itself
13:21:55 [ericP]
hknublau: classes can't have constraints
13:22:06 [ericP]
... they have to be attached to the shape
13:22:32 [ericP]
Arnaud: your class would have to be a shape
13:22:43 [ericP]
... in which case it could ahve constraints
13:23:26 [pfps]
hmm, you may also need the correct typing, as SHACL can't infer it
13:24:24 [hsolbrig]
q-
13:24:59 [ericP]
hknublau: any decent RDFS tools should treat @@1 as a class because it's a meta-class
13:26:06 [ericP]
pfps: if shacl had RDFS (domains and ranges) then all you'd need is one triple to assert that a class is a shape
13:26:30 [ericP]
q+
13:26:40 [Arnaud]
ack ericP
13:27:24 [iovka]
ericP: we resolved that we do not have a type arc on the shape
13:27:53 [ericP]
hknublau: most databaes don't implement RDFS or you can't control it
13:28:19 [ericP]
... we'd still need to triples
13:28:46 [ericP]
Arnaud: in TBC, wouldn't that be hidden from users?
13:28:59 [ericP]
hknublau: in TBC, everything is class-driven
13:29:17 [pfps]
With the new resolution on optional typing in SHACL the type links would be optional, so only one triple is needed overall
13:32:02 [ericP]
hknublau: most people will start with an existing class and need to add shape constriants
13:33:19 [ericP]
Arnaud: i think a dummy user will understand adding the shapeClass to merge two concepts
13:33:40 [ericP]
hknublau: we spin, we had only classes and constraints and folks were happy about it
13:33:59 [ericP]
Arnaud: if folks only have classes, then they have to be happy about it.
13:34:49 [ericP]
... but i appreciate that your customers are using classes
13:36:27 [kcoyle]
q+
13:36:35 [ericP]
ericP: how much extra work is it to use X sh:shapeClass X insetad of X a sh:ShapeClass?
13:36:59 [phila]
phila has joined #shapes
13:37:07 [pfps]
Then how does no typing on blank nodes work?
13:37:35 [ericP]
hknublau: it requires inferencing so we need another layer arbound databases
13:39:41 [Arnaud]
q?
13:41:33 [Arnaud]
ack kcoyle
13:42:15 [ericP]
kcoyle: is this issue going to be hidden in the draft?
13:42:39 [ericP]
Arnaud: we can resolve this and then it disappears (though nothing prevents us from asking for comments)
13:43:00 [ericP]
... but if we want feedback, it's better to ask for feedback with a pointer to an issue
13:43:59 [ericP]
... if we ask the question, we'll just keep getting the same responses. we alrady know the spectrum
13:44:16 [pfps]
q+
13:44:20 [pfps]
q-
13:44:49 [Arnaud]
PROPOSED: Close ISSUE-23 allowing for ShapeClass, adding a note about the possible pitfalls of conflating classes and shapes
13:44:55 [pfps]
one feedback that we might get is that we are stepping on RDFS's tender toes
13:45:01 [hknublau]
+1
13:45:14 [aryman_]
+0
13:45:24 [pfps]
-0.9 the writing on the note is going to be tricky
13:45:30 [simonstey]
+0 (seeing peter's point wrt. rdfs)
13:45:38 [Dimitris]
+0
13:45:40 [ericP]
-1
13:45:44 [hsolbrig]
-.5
13:45:52 [Labra]
-1
13:46:24 [kcoyle]
+0
13:47:00 [simonstey]
what should be possible is a) to associate shapes on the instance level or b) on the class level
13:47:06 [iovka]
-1
13:47:30 [pfps]
we do have both instance-level shapes and class-level shapes already
13:48:06 [simonstey]
therefore I'm happy ;)
13:49:43 [ericP]
Arnaud: clearly can't close this now. we'll go with kcoyle's proposal to publish and ask for opinions, though i think we already know the what we'll hear.
13:50:55 [pfps]
I had some sympathy for Holger's complaint.
13:51:25 [aryman_]
I am OK with syntactic sugar given that there is no change to expressive power
14:01:51 [Arnaud]
q?
14:09:58 [hknublau]
hknublau has joined #shapes
14:11:01 [aryman]
aryman has joined #shapes
14:13:13 [Arnaud]
pfps, are you back?
14:14:23 [pfps]
almost
14:15:30 [pfps]
present+ pfps
14:16:15 [ericP]
Arnaud: pfps, you objected to closing issue-74 and i wanted to give you an op to make your case
14:16:15 [Arnaud]
topic: Issue-74
14:16:19 [Arnaud]
issue-74
14:16:19 [trackbot]
issue-74 -- Should SHACL support validating RDF graphs accessible via unmodified SPARQL endpoints -- closed
14:16:19 [trackbot]
http://www.w3.org/2014/data-shapes/track/issues/74
14:17:16 [ericP]
pfps: i sympathize with Dimitris's position (at least from reading the minutes).
14:17:39 [ericP]
... one thing i'd like to do is to run validation on external data, e.g. dbpedia
14:18:56 [ericP]
... there are some probs with dbpedia data. i'd like to be able to examine that with shacl, but i need it to work over SPARQL
14:19:23 [ericP]
q+ to point out that the same prob applies to local SPARQL queries
14:19:45 [ericP]
Arnaud: that seems desirable, but the bar seems to high
14:19:52 [Arnaud]
ack ericP
14:19:52 [Zakim]
ericP, you wanted to point out that the same prob applies to local SPARQL queries
14:20:55 [ericP]
ericP: blah blah blah told blank nodes blah blah blah
14:21:18 [ericP]
pfps: there are more issues not related to blank nodes but just resource considerations
14:21:38 [ericP]
... i'm in favor of Dimitris's proposal to have a summary mode
14:21:52 [Arnaud]
PROPOSED: Confirm resolution of ISSUE-74 as is
14:21:56 [ericP]
+1
14:22:04 [hknublau]
+1
14:22:06 [simonstey]
+0
14:22:13 [iovka]
+1
14:22:19 [Arnaud]
RESOLVED: Confirm resolution of ISSUE-74 as is
14:22:54 [Arnaud]
topic: issue-22
14:22:56 [Arnaud]
issue-22
14:22:56 [trackbot]
issue-22 -- Treatment of recursive shape definitions -- open
14:22:56 [trackbot]
http://www.w3.org/2014/data-shapes/track/issues/22
14:23:24 [ericP]
Arnaud: hknublau, what's the current editor's draft say?
14:24:00 [ericP]
hknublau: we've implemented a guard mechanism which when it seems the same node/shape combination, it throws an error
14:24:42 [ericP]
Arnaud: we've been through this before and it came down to three options when you detect a cycle:
14:24:56 [ericP]
... 1 i've been here before so it's valid
14:25:08 [ericP]
... 2 i've been here before so it's not valid
14:25:08 [pfps]
this is, of course, if you want to have recursive shapes
14:25:24 [ericP]
... 3 i've been here before so there's an error
14:25:43 [ericP]
hknublau: and we ignore e.g. disjunction
14:26:17 [aryman]
q+
14:26:18 [ericP]
Arnaud: some people want to have recursive shapes.
14:26:29 [Arnaud]
ack aryman
14:26:34 [ericP]
... pfps said in a previous call that you could handle recursion in some cases
14:26:47 [ericP]
aryman: support recursion:
14:26:55 [ericP]
... need migration path for OSLC
14:27:31 [ericP]
... possible to give recursion a defined meaning. created a wiki page for use cases
14:27:32 [pfps]
I have not had a chance to look at that wiki after the first week or so
14:27:37 [pfps]
pointer to document??
14:28:01 [ericP]
... i wrote up recursion as it exists in OSLC but it doesn't include negation
14:28:37 [ericP]
... negation available in SHACL as NOT and XOR
14:28:38 [Arnaud]
http://arxiv.org/abs/1505.04972
14:28:53 [ericP]
... iovka, what's the status of the semantics doc?
14:29:46 [kcoyle_]
kcoyle_ has joined #shapes
14:30:16 [ericP]
iovka: i'm not working on that doc anymore.
14:30:29 [ericP]
... there are one or two typos, but it's stable
14:31:12 [ericP]
... we are continuing to work on a well-founded semantics for ShEx.
14:31:23 [ericP]
Arnaud: do we want some level of recursion?
14:32:02 [ericP]
... do we want some form of recursion? if so, what are the limitations?
14:32:23 [pfps]
arthur - is there a description of recursion in the OSLC documents?
14:32:56 [ericP]
... do we make a general rule and deal with corner cases?
14:33:00 [aryman]
@pfps - the OSLC specs are very informal
14:33:10 [ericP]
iovka: recursion can work as long as there is no negation to be verified
14:33:15 [ericP]
... negation can be hidden
14:33:44 [pfps]
@arthur - even an informal discussion of recursion? - or even an implementation that handles recursion?
14:34:05 [ericP]
... if i define <S> EXTRA :shoeSize { :shoeSize xsd:integer {1} }, we have a hidden negation.
14:34:28 [ericP]
... if it's an integer, that's easy; harder when it's a shape ref
14:35:03 [pfps]
s/least/greatest/?
14:35:47 [ericP]
... there is a maximal typing which corresponds to a greatest fixed point in which every node gets all of its possible shapes
14:36:14 [pfps]
q+
14:36:17 [ericP]
... if i have nodes and want them to satisfy shapes, i can create a least fixed typing
14:36:28 [aryman]
@pfps - the OSLC specs don't discuss recursion explicitly, and don't exclude recursive shapes
14:36:31 [Arnaud]
ack pfps
14:36:40 [ericP]
... there is also a notion of minimal typing if i call the algorithm with some initial requirements
14:37:11 [ericP]
... so now two meanings for recursion (least/greatest)?
14:37:42 [elf-pavlik]
elf-pavlik has joined #shapes
14:38:07 [pfps]
I'm confused
14:39:02 [ericP]
... for me, recursion is visiting the same node with the same type, but apparently there's a definition that involves any cycle in the graph.
14:39:43 [ericP]
... whether a shape is negated can be tested by evaluating a finite neighborhood.
14:40:02 [ericP]
Arnaud: so you limit negation to make it work?
14:40:22 [ericP]
iovka: you can include negation, but not if there's a recursion.
14:40:46 [ericP]
Arnaud: what happens if i violate this?
14:41:25 [ericP]
ericP: static analysis error -- property of the shape, not the pairing of the shape and the class
14:41:49 [ericP]
iovka: you have a lattice of typing which associates typing to nodes.
14:41:58 [ericP]
... in this lattice there is a greatest fixed point typing
14:42:07 [ericP]
... there is no least fixed point in this lattice
14:42:25 [pfps]
the question is whether <s> { ex:a @<s> [1,1] } is "satisfied" by ex:a ex:b ex: a . from an empty initial typing
14:42:51 [ericP]
... but if we give an initial typing and we suppose that there is an ordering on the neighborhood, e.g. that of the SPARQL ORDER BY, then this lattice provides a least fixed point.
14:44:50 [pfps]
the question is whether <s> { ex:b @<s> [1,1] } is "satisfied" by ex:a ex:b ex: a . from an empty initial typing
14:47:22 [ericP]
pfps: suppose we turn this into a shacl opperation.
14:47:42 [ericP]
... under one proposal, the answer could be yes
14:48:05 [ericP]
... saying that ex:a belongs to <s> doesn't map to shacl.
14:48:15 [ericP]
Arnaud: there are two qs:
14:48:31 [ericP]
... .. does that shape <s> apply to ex:a?
14:48:48 [ericP]
... .. does ex:a satisfy <s>
14:53:33 [Arnaud]
is <s> { ex:b @<s> [1,1] } "satisfied" by ex:a sh:nodeShape <s>; ex:b ex:a .
14:54:07 [pfps]
the claim is that there is a unique consensus view of what certain kinds of recursion "mean". I had thought that ShEx had a particular viewpoint on this, but now I'm confused.
14:54:46 [ericP]
... if we make the link between the node and the shape explicit, [see shape above]
14:55:08 [pfps]
so can you ask about partial assignments?
14:55:49 [ericP]
iovka: the ShEx POV is "yes" because there is a way to make ex:a match <S>
14:56:10 [ericP]
... there is at least one in which ex:a satisfies <s>
14:56:28 [pfps]
I'm coming to the viewpoint that we have to yet again defer this issue
14:56:36 [aryman]
@simonstey thx
14:57:19 [ericP]
Arnaud: i don't expect us to close this but i'd like some sort of direction
14:57:58 [ericP]
pfps: one way forward with some WG support is, for the non-controversial cases, SHACL takes the same view of reality as everyone else does
14:58:16 [ericP]
... that's recursion with no negation at all
14:58:29 [ericP]
... now i'm not even sure that that's the case.
14:58:37 [ericP]
... a way forward:
14:58:53 [ericP]
... when someone wants recursion in SHACL, come up with a proposal for it.
14:59:05 [ericP]
... we have a proposal from hknublau
14:59:24 [ericP]
... it's reasonably well-defined
14:59:49 [ericP]
... the gist is whenever you encounter a dataloop in negation, you get an error
15:00:16 [aryman]
q+
15:01:37 [Arnaud]
ack aryman
15:02:25 [ericP]
pfps: SHACL will fail some cases where ShEx won't: a non-negated cycle
15:02:40 [pfps]
I have several examples that show how hard recursion through negation is
15:02:57 [ericP]
... ShEx will fail some cases where SHACL won't: a negated recursion tested against a graph without a cycle
15:03:43 [ericP]
aryman: let's punt with static analysis
15:03:58 [ericP]
... i'd be happy to write up the added runtime context
15:04:07 [ericP]
pfps: if they're willing to work on it, sure.
15:04:39 [ericP]
... my last reading of OSLC, it doesn't talk about recursion
15:05:12 [ericP]
... this is aryman's paper
15:05:53 [ericP]
Arnaud: aryman has volunteered to document OSLC plus the ShEx static analysis
15:06:21 [pfps]
fine by me, as I don't have anything to do :-)
15:07:03 [ericP]
ACTION: aryman to provide a proposal for recursion (from OSCL + ShEx static analysis)
15:07:03 [trackbot]
Created ACTION-29 - Provide a proposal for recursion (from oscl + shex static analysis) [on Arthur Ryman - due 2015-09-15].
15:07:21 [pfps]
I've already done my action from before
15:08:09 [ericP]
hknublau: there are 84 proposed extensions to be added to the core
15:08:25 [ericP]
... how do we define core? macro mechanism? spin off anothehr library?
15:08:41 [ericP]
Arnaud: kcoyle_ asked on the mailing list "who defines the core?"
15:08:47 [ericP]
... i said "we do"
15:08:59 [ericP]
... there are different extremes that we can adopt.
15:09:13 [ericP]
... .. no core: start with nothing and let the community decide
15:09:31 [ericP]
... .. phat core: put everything in hoping we satisfy everyone
15:09:38 [ericP]
... .. middle ground
15:09:54 [ericP]
... there's no hard rule for how to do this.
15:10:14 [ericP]
... we started with a smaller core, but several features where added based on feedback from WG members
15:10:39 [hknublau]
q+
15:10:45 [ericP]
... every time someone says "how do i do this?" and the answer is "extension" and you disagree, you can make a case for adding it to the core.
15:10:56 [ericP]
... we won't find a general rule for what's in/out of core
15:11:40 [ericP]
... working on the test-suite and the user-friendly syntax will clarify
15:11:40 [Arnaud]
ack hknublau
15:11:53 [ericP]
hknublau: in SPIN we have multiple namespaces
15:12:09 [ericP]
... .. "core" has everything that needs hard-coding
15:12:31 [ericP]
... .. "spl" has stuff that's not as central -- doesn't require hard-coding
15:12:43 [ericP]
... much easier to add to "spl"
15:13:40 [ericP]
... we have probably covered 80%. do we open another library for the next 5% with a different delivery ccyle
15:13:45 [ericP]
... ?
15:14:35 [ericP]
Arnaud: there's a standard library for C, but it's not part of the languauge
15:14:51 [ericP]
kcoyle_: what would that consist of?
15:15:01 [ericP]
Arnaud: stuff we find useful
15:15:10 [ericP]
kcoyle_: templates? extensions?
15:15:24 [ericP]
Arnaud: features we'd expect every implementation to support
15:15:28 [kcoyle_]
q+
15:15:42 [ericP]
... unless someone wants to make a strong case for splitting it, let's just use core
15:15:49 [Arnaud]
ack kcoyle_
15:15:57 [aryman]
q+
15:15:58 [ericP]
... right now i think our q is do we have enough in the core to satisfy everyone?
15:16:18 [simonstey]
all built-in concepts -> core; custom functions, custom templates, native constraints -> advanced part
15:16:20 [ericP]
kcoyle_: we had two mechanisms brough up by philA and myself
15:16:27 [ericP]
... do we careate issues for those?
15:16:31 [Arnaud]
ack aryman
15:16:36 [ericP]
Arnaud: i think so
15:17:01 [ericP]
aryman: OSLC experience with creating multiple namespaces proved to be problematic
15:17:23 [ericP]
... we strech the analogy between package names and namespaces a little too far
15:18:56 [ericP]
... don't create too many namespaces
15:19:06 [ericP]
Arnaud: my proposal is to stick with one core
15:21:06 [Labra]
scrinick: Labra
15:21:37 [Arnaud]
scribenick: Labra
15:22:12 [ericP]
issue-84
15:22:12 [trackbot]
issue-84 -- Constraint to limit IRIs of focus nodes to a given enumeration (similar to owl:oneOf) -- open
15:22:12 [trackbot]
http://www.w3.org/2014/data-shapes/track/issues/84
15:22:28 [Labra]
hknublau:
15:22:51 [Labra]
hknublau: The use case is that you have a list of values equivalent to oneOf constraint in OWL
15:23:00 [pfps]
SHACL already has the ability to do this, via an or of hasValues
15:23:06 [Labra]
ericP: OSLC has hasValue or something like that
15:23:31 [Labra]
ericP: in SHACL we have the same thing
15:23:49 [Labra]
hknublau: the difference is that this one is global
15:23:55 [pfps]
s/SHACL already has the ability to do this, via an or of hasValues//
15:24:51 [Labra]
hknublau: an example in Peter's review is that you don't need to create a class to enumerate...you specify that a class has those values
15:25:24 [Labra]
EricP: with nodekind and a valueset we don't need that mechanism
15:25:47 [Labra]
hknublau: we don't want to repeat the same enumeration
15:25:50 [pfps]
you don't have to repeat in SHACL - you can just reuse
15:26:16 [Labra]
hknublau: it is global
15:27:16 [aryman]
q+
15:27:38 [Labra]
Arnaud: asks if it is true that it can be done with an or
15:27:42 [Labra]
pfps: maybe
15:28:09 [Labra]
pfps: it falls to the notion of what is a shape, what is a constraint and how you combine them
15:28:22 [pfps]
hmm, I may have been done in twice by the odd syntax of SHACL
15:29:25 [aryman]
fyi, OSLC uses oslc:AllowedValues class to specify closed sets of values. http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#AllowedValues
15:29:34 [Labra]
pfps: they are neither shapes nor constraints
15:30:20 [Labra]
pfps: what is sh:minCount 1 ? is it a constraint?
15:30:23 [simonstey]
sh:PropertyConstraint a sh:ConstraintTemplate ; rdfs:subClassOf sh:AbstractAllowedValuesPropertyConstraint ; etc.
15:30:39 [Labra]
hknublau: it is something that gets instantiated
15:31:29 [simonstey]
it works afaik
15:32:11 [Labra]
pfps: you have to wrap it into a constraint
15:32:42 [simonstey]
yes
15:33:23 [Arnaud]
ack aryman
15:33:44 [Labra]
aryman: OSLC had a similar feature
15:33:55 [Labra]
...it was useful to predefine things
15:34:11 [Labra]
...you could refer to those resources to store common used categories
15:34:12 [ericP]
q+
15:34:46 [Arnaud]
ack ericP
15:34:52 [Labra]
pfps: why we should pick just on this one
15:35:04 [Labra]
ericP: we did that in shex in the grammar
15:35:34 [kcoyle_]
q+
15:35:40 [Labra]
...you can define a valueConstraint and reuse it and we were wondering how to translate that to SHACL
15:36:17 [Labra]
...and asks why only on value sets
15:37:02 [Arnaud]
ack kcoyle_
15:37:15 [pfps]
but I think that what Eric is saying can be done already
15:37:39 [Labra]
karen: how to constrain values to vocabularies
15:37:55 [pfps]
I think, however, is what Eric wants is to have not just enumerated sets, but also the "set" of numbers between 1 and 20
15:37:58 [Labra]
ericP: you can enumerate the values even dynamically
15:39:04 [Labra]
ericP: it can be a macro
15:40:08 [Labra]
...instead of having another property...you can have other property where you capture all that stuff
15:40:24 [Labra]
...it is not a proposal as such....but I can write it
15:41:36 [Labra]
...if you apply a context to JSON-LD it falls out of it
15:41:58 [ericP]
PROPOSAL: a sh:Property class have an sh:value property which points to a value class. all restrictions on values go into an instance of that class.
15:43:58 [Labra]
hsolbrig: we had another requirement where the valueclass could be external
15:44:12 [Labra]
...and the engine could look for it...
15:44:22 [Labra]
...and you could capture that stuff in SHACL
15:45:12 [ericP]
<S> a sh:Shape ; sh:property my:juvenileAge ; sh:value [ a sh:ValueConstraint ; sh:pattern "..." ] ] .
15:45:55 [simonstey]
sh:property [ sh:predicate my:
15:46:09 [ericP]
<S> a sh:Shape ; sh:property [ sh:predicate my:juvenileAge ; sh:value [ a sh:ValueConstraint ; sh:pattern "..." ] ] ] .
15:46:09 [hsolbrig]
Rochester, MN (CDT). 10:45 AM
15:46:57 [simonstey]
http://w3c.github.io/data-shapes/shacl/#AbstractPatternPropertyConstraint
15:47:53 [ericP]
<S> a sh:Shape ; sh:property [ sh:predicate my:juvenileAge ; sh:value [ a sh:ValueConstraint ; sh:nodeType xsd:integer ; sh:minExclusive 1; sh:pattern "..." ] ] ] .
15:48:39 [Labra]
ericP: you stick all the things that you stick in an object in a node
15:49:03 [Labra]
ericP: you take advantage of the RDF graph...for reusability
15:49:54 [aryman]
sh:hasValue restricts the value
15:51:34 [simonstey]
+1 to extend the hasvalue concept
15:52:00 [Labra]
hknublau: the closest concept to this is functions
15:52:22 [Labra]
...in principle we could allow people to use instances of those evaluation functions
15:53:03 [hknublau]
sh:validationFunction
15:53:04 [ericP]
http://www.w3.org/2005/01/yacker/uploads/ShEx3?lang=perl&markup=html#prod-ShEx3-valueClassDefinition
15:53:11 [Labra]
Arnaud: we should leave it as is...it seems there is a gap in the spec that is missing
15:53:19 [phila]
phila has joined #shapes
15:53:29 [ericP]
http://www.w3.org/2005/01/yacker/uploads/ShEx3?lang=perl&markup=html#prod-ShEx3-valueClass
15:54:10 [Labra]
Arnaud: tomorrow we will talk about the user friendly syntax
15:54:21 [Labra]
and how we could have a proposal to put on the table
15:54:31 [Labra]
we will also talk about the test-suite
15:54:55 [Labra]
PhilA will join us tomorrow
15:55:45 [Arnaud]
trackbot, end meeting
15:55:45 [trackbot]
Zakim, list attendees
15:55:45 [Zakim]
As of this point the attendees have been hknublau, Dimitris, ericp, Arnaud, iovka, aryman, pfps, hsolbrig, simonstey
15:55:53 [trackbot]
RRSAgent, please draft minutes
15:55:53 [RRSAgent]
I have made the request to generate http://www.w3.org/2015/09/08-shapes-minutes.html trackbot
15:55:54 [trackbot]
RRSAgent, bye
15:55:54 [RRSAgent]
I see 1 open action item saved in http://www.w3.org/2015/09/08-shapes-actions.rdf :
15:55:54 [RRSAgent]
ACTION: aryman to provide a proposal for recursion (from OSCL + ShEx static analysis) [1]
15:55:54 [RRSAgent]
recorded in http://www.w3.org/2015/09/08-shapes-irc#T15-07-03