17:58:38 <RRSAgent> RRSAgent has joined #shapes
17:58:38 <RRSAgent> logging to http://www.w3.org/2015/06/18-shapes-irc
17:58:40 <trackbot> RRSAgent, make logs rdf-data-shapes
17:58:40 <Zakim> Zakim has joined #shapes
17:58:42 <trackbot> Zakim, this will be SHAPES
17:58:42 <Zakim> ok, trackbot; I see DATA_RDFWG()2:00PM scheduled to start in 2 minutes
17:58:43 <trackbot> Meeting: RDF Data Shapes Working Group Teleconference
17:58:43 <trackbot> Date: 18 June 2015
17:58:45 <hknublau> hknublau has joined #shapes
17:59:10 <Arnaud> present+ Arnaud
18:00:11 <simonstey> it's actually shapes
18:00:17 <hsolbrig> hsolbrig has joined #shapes
18:00:21 <simonstey> present+ simonstey
18:00:40 <kcoyle> present+ kcoyle
18:03:42 <Labra> Labra has joined #shapes
18:04:33 <hknublau> present+ hknublau
18:05:08 <Arnaud> present+ labra
18:05:44 <Arnaud> present +aryman
<Arnaud> present +pfps
18:06:20 <TallTed> TallTed has changed the topic to: RDF Data Shapes WG: https://www.w3.org/2014/data-shapes - Next agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2015.06.18 ** Beware: We're using WebEx this week!! **  audio link: https://mit.webex.com/mit/j.php?MTID=m3f7be74bc0d7a0abf0405fe5661ee163
18:06:41 <Arnaud> chair: Arnaud
18:06:46 <aryman> scribe: aryman
18:06:53 <Arnaud> agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2015.06.18
<aryman> topic: Admin
18:07:07 <Arnaud> PROPOSED: Approve minutes of the 11 June Telecon: http://www.w3.org/2015/06/11-shapes-minutes.html
18:07:14 <pfps> minutes look fine
18:07:19 <Arnaud> RESOLVED: Approve minutes of the 11 June Telecon: http://www.w3.org/2015/06/11-shapes-minutes.html
18:08:43 <aryman> TOPIC: Disposal of raised ISSUE-66
18:09:55 <Dimitris> Dimitris has joined #shapes
18:11:18 <Arnaud> present+ TallTed
18:11:35 <aryman> TallTed: asks for descriptive names for bugs
18:14:29 <Arnaud> present+ ericP
18:14:44 <Arnaud> present+ Dimitris
18:18:27 <aryman> q+
18:18:31 <Arnaud> ack aryman
18:18:48 <Arnaud> issue-66
18:18:48 <trackbot> issue-66 -- bug in SHACL spec -- raised
18:18:48 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/66
18:19:12 <hknublau> Can we just open this and move on? We already had 10 minutes last time…
18:20:14 <TallTed> +1 open it!  :-)
18:20:20 <Arnaud> PROPOSED: Open ISSUE-66: SHACL spec ill-founded due to non-convergence on data loops
18:20:33 <aryman> pfps: changed title to "spec ill-founded due to non-convergence on data loops"
18:20:41 <simonstey> +1
18:20:46 <hknublau> +1
18:20:51 <Labra> +1
18:20:52 <pfps> +1
18:20:53 <aryman> +1
18:20:58 <Dimitris> +1
18:20:58 <ericP> +1
18:21:00 <kcoyle> +1
18:21:11 <Arnaud> RESOLVED: Open ISSUE-66: SHACL spec ill-founded due to non-convergence on data loops
18:21:21 <Arnaud> ISSUE-68
18:21:21 <trackbot> ISSUE-68 -- pre-binding not defined in SHACL spec -- raised
18:21:21 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/68
18:21:22 <hknublau> +q
18:21:28 <aryman> TOPIC: Disposal of raised ISSUE-68
18:21:30 <Arnaud> ack hknublau
18:22:02 <Arnaud> PROPOSED: Open ISSUE-68: pre-binding not defined in SHACL spec
18:22:39 <aryman> +1
18:22:42 <ericP> +1
18:22:42 <hknublau> +1
18:22:43 <Dimitris> +1
18:22:43 <TallTed> +1
18:22:45 <pfps> +1
18:22:45 <Labra> +1
18:22:47 <kcoyle> +1
18:22:47 <simonstey> +1
18:22:52 <Arnaud> RESOLVED: Open ISSUE-68: pre-binding not defined in SHACL spec
18:22:52 <hsolbrig> +1
18:23:19 <aryman> TOPIC: SHACL Formal Definition
18:24:10 <aryman> q+
18:24:20 <Arnaud> http://w3c.github.io/data-shapes/shacl-ref/
18:25:47 <aryman> fyi, here is HTML generated from an RDFS Turtle vocab at IBM: https://jazz.net/wiki/bin/view/LinkedData/JazzProcessVocabulary
18:27:01 <Arnaud> ack aryman
18:27:42 <pfps> q+
18:27:58 <pfps> q+ to ask what "long term" is involved here
18:28:27 <aryman> aryman: how was the doc generated?
18:29:08 <aryman> hknublau: I used a TopBraid feature called SPARQL Web Pages (SWP)
18:29:11 <Arnaud> ack pfps
18:29:11 <Zakim> pfps, you wanted to ask what "long term" is involved here
18:29:48 <aryman> Arnaud: agree that we should have non-commercial tools
18:29:57 <aryman> q+
18:30:23 <aryman> pfps: what long term maintenance issues are there?
18:30:25 <Arnaud> ack aryman
18:32:02 <aryman> aryman: we should automate the build chain as much as possible, e.g. to correct typos, improve text etc.
18:32:20 <pfps> q+ to ask what the scope of this document is supposed to be
18:32:51 <Arnaud> ack pfps
18:32:51 <Zakim> pfps, you wanted to ask what the scope of this document is supposed to be
18:32:59 <aryman> Arnaud: what is the relation of the generated HTML to the other specs? which is normative?
18:34:11 <aryman> q+
18:34:16 <Arnaud> ack aryman
18:35:11 <pfps> I don't think that the document is going to define the semantics of SHACL.
18:35:47 <pfps> q+ to talk about W3C publishing normative machine-readable documents
18:36:38 <Arnaud> ack pfps
18:36:38 <Zakim> pfps, you wanted to talk about W3C publishing normative machine-readable documents
18:37:15 <aryman> aryman: the Turtle vocab should be normative, published on the web, and serve up HTML as per W3C recommendations
18:37:54 <aryman> aryman: also we should have a normative SHACL document to describe SHACL documents, but probably need to augment that with normative prose
18:38:35 <pfps> q+
18:39:03 <aryman> @ericP: avoid duplication of source, include generated HTML in hand-written HTML spec
18:39:08 <aryman> q+
18:39:17 <Arnaud> ack pfps
18:40:10 <aryman> pfps: expresses concern about W3C hosting things like DTDs due to serve load
18:40:31 <aryman> @ericP: W3C rate-limits requests
18:41:05 <aryman> pfps: What if SHACL can't fully describe SHACL?
18:44:03 <aryman> I expect SHACL to describe syntax only, but possibly not even completely
18:45:49 <Arnaud> ack aryman
18:46:33 <pfps> Having the document under access control because it is served via content negotiation and the ttl version is being hit hard is not a good situation.
18:46:38 <aryman> hknublau: continue for now with the two documents 1) manual 2) generated, get rid of the appendix
18:47:40 <pfps> The current document provides a lot of stuff that looks like semantics - what status does this part of the document have?
18:49:56 <aryman> @pfps we still need the semantics written down precisely somewhere - if that can be in the comments of the vocab, then fine
18:50:22 <hknublau> Yes to improving the rdfs:comments
18:50:50 <aryman> suggest we look at integrating the HTML generation into ReSpec, c.f. work down by Steve Speicher for OSLC Shapes
18:50:50 <pfps> Well then what is the status of the comments?
18:50:58 <aryman> s/down/done/
18:51:51 <aryman> @pfps we can say the comments are normative if that is the best approach, otherwise don't put the semantics in the vocab doc - avoid duplication
18:52:10 <pfps> Even if the redundancies are pulled out of the other document, the remaining definitional parts will still be scattered.
18:52:25 <hknublau> +q
18:52:30 <Arnaud> ack hknublau
18:52:44 <aryman> TOPIC: ISSUE-1
18:53:23 <aryman> hknublau: we can split this issue up into a few proposals
18:54:01 <aryman> hknublau: We cannot rely on inferencing being available, so we need to do some in the SHACL engine
18:54:56 <aryman> hknublau: Main use case is for subclass inferencing in valueType and classScope, i.e. use rdf:type;rdfs:subClassOf*
18:55:26 <aryman> hknublau: But in OSLC Shapes there is no subclass inferencing
18:56:01 <pfps> q+
18:56:06 <Arnaud> ack pfps
18:56:12 <aryman> q+
18:56:43 <aryman> pfps: bad idea to just to rdfs:subClassOf*
18:58:03 <Arnaud> ack aryman
18:58:04 <pfps> I'm against implementing yet another kind of inference.
18:58:10 <aryman> pfps: SHACL should repect RDFS semantics
19:00:21 <simonstey> +q
19:00:27 <Arnaud> ack simonstey
19:00:44 <pfps> I'm not in favour of a solution that uses RDF and RDFS terms without considering their meaning in RDF or RDFS.  This is, in effect, what the rdf:type/rdfs:subClassOf* solution is doing.
19:00:53 <aryman> I suggest we avoid claiming "inferencing" and simply provide pairs of vocab terms, one for rdf:type and another for rdf:type;rdfs:subClassOf*
19:01:46 <aryman> simonstey: the language will get too complicated if we introduce many variants of paths (I want property paths too!)
19:01:55 <Dimitris> +q
19:02:43 <Arnaud> ack Dimitris
19:03:07 <aryman> hsolbrig: I favor the "do nothing" approach, i.e. SHACL is given a graph, the environment is responsible for producing the graph, with or without inferencing
19:03:26 <hknublau> q+
19:03:41 <aryman> Dimitris: agree with Holger and Arthur that the subclass use case is very important
19:03:47 <Arnaud> ack hknublau
19:04:00 <pfps> I'm definitely saying that RDFS inferencing is my preferred solution.
19:04:29 <pfps> q+
19:04:30 <hsolbrig> q+
19:04:31 <simonstey> +1 to holger's point
19:04:53 <aryman> hknublau: "do nothing" is not realistic since the use of ontologies raises expectations for subclass paths
19:05:33 <Arnaud> ack pfps
19:05:45 <aryman> hknublau: RDFS inferencing is not implemented uniformly
19:06:23 <aryman> pfps: Why does the subclass portion of RDFS get preferential treatment?
19:06:44 <pfps> it's not just rdfs:domain and rdfs:range, it's also subproperties of rdfs:subClassOf
19:06:51 <Arnaud> ack hsolbrig
19:07:13 <aryman> hknublau: rdfs:domain and rdfs:range are not important for SHACL, but rdfs:subClassOf is
19:07:59 <aryman> hsolbrig: We should rely on SPARQL enpoints to do the inferencing
19:08:09 <aryman> q+
19:08:15 <pfps> rdfs:subPropertyOf is also important, I think
19:08:19 <hknublau> Straw poll at least?
19:08:43 <Arnaud> ack aryman
19:08:49 <aryman> Arnaud: more people should propose solutions to this ISSUE
19:10:23 <Arnaud> STRAWPOLL: a) no inferencing whatsover, b) rdfs inferencing all the way, c) something in between (e.g. support a few things like rdfs:subClassOf)
19:10:23 <hsolbrig> +1 to Arthur's suggestion
19:11:11 <hknublau> Yes this property already exists in the proposal, sh:sparqlEntailment
19:11:19 <hknublau> but this is for custom SPARQL queries only.
19:12:27 <pfps> I thought that we were moving on
19:12:47 <ericP> +1 to arthur's approach
19:13:17 <ericP> which i read as consistent with harold's proposal
19:13:17 <aryman> TOPIC: ISSUE-47
19:13:17 <Arnaud> issue-47
19:13:17 <trackbot> issue-47 -- Can SPARQL-based constraints access the shape graph, and how? -- open
19:13:17 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/47
19:13:53 <Dimitris> +q
19:13:58 <Arnaud> ack Dimitris
19:15:01 <aryman> Dimitris: OK if used just by core language. Are there good use cases for extensions to access the shape graph?
19:15:07 <pfps> I'm confused - the core language doesn't seem to need such access, it is only in the extensions and the SPARQL portions that access is used
19:15:32 <aryman> @pfps - the core uses if for closed shapes
19:15:32 <hknublau> +q
19:15:39 <aryman> s/if/it/
19:15:43 <Arnaud> ack hknublau
19:16:14 <pfps> the core language does not use such access for closed shapes - only the SPARQL code does, which is not part of the core language
19:17:02 <pfps> q+
19:17:08 <aryman> @pfps, the semantics of the core language is defined by SPARQL so it affects what SPARQL is generated
19:17:43 <pfps> is the semantics of the core language defined by SPARQL?  is that in the current document?
19:17:49 <aryman> hknublau: this issue affects how SPARQL is generated
19:18:32 <Arnaud> ack pfps
19:19:04 <aryman> pfps: Why does the core need this?
19:20:46 <hknublau> +q
19:20:47 <aryman> pfps: Access to the shape graph rules out important use cases, e.g. SPARQL endpoints, services
19:20:48 <pfps> I'm saying that the core doesn't need this
19:21:10 <Arnaud> ack hknublau
19:21:43 <pfps> the current document not only allows access to the shape graph when evaluating constraints on the data graph but *requires* that this acccess is possible in all cases
19:21:46 <aryman> hknublau: the current implementation provides the shape graph as a named graph via "shapeGraph" variable
19:21:48 <pfps> q+
19:21:50 <Dimitris> +q
19:23:29 <Arnaud> ack pfps
19:23:49 <aryman> hknublau: the engine should fail gracefully, i.e. if the shapeGraph is not available then fail
19:24:23 <aryman> pfps: AFAIK only recursion requires access to the shapeGraph
19:24:31 <Arnaud> ack Dimitris
19:24:43 <pfps> and other constructs can be  effectively implemented wihtout such access
19:25:36 <pfps> q+
19:25:49 <aryman> Dimitris: I don't want to limit the whole language if the shapeGraph is not available in all use cases
19:25:59 <pfps> q-
19:26:34 <hknublau> My proposal is in the spec, plus have a separate document for SPARQL endpoints.
19:28:04 <hknublau> +q
19:28:25 <Arnaud> ack hknublau
19:28:25 <aryman> pfps: Current spec is written assuming that the shapeGraph is available in many case. My proposal did not require the shapeGraph.
19:29:15 <Dimitris> my proposal is that if there are no use cases, disable access outside of the core language
19:29:36 <aryman> hknublau: The implementations can avoid the shapeGraph in the cases where it is not needed. The use of the shapeGraph makes the spec simpler.
19:30:20 <aryman> Arnaud: members should review the proposals
19:30:39 <Arnaud> trackbot, end meeting
19:30:39 <trackbot> Zakim, list attendees
19:30:39 <Zakim> sorry, trackbot, I don't know what conference this is
19:30:47 <trackbot> RRSAgent, please draft minutes
19:30:47 <RRSAgent> I have made the request to generate http://www.w3.org/2015/06/18-shapes-minutes.html trackbot
19:30:48 <trackbot> RRSAgent, bye
19:30:48 <RRSAgent> I see no action items
19:31:36 <RRSAgent> RRSAgent has joined #shapes
19:31:36 <RRSAgent> logging to http://www.w3.org/2015/06/18-shapes-irc
19:31:54 <Arnaud> RRSAgent, bye
19:32:29 <Arnaud> RRSAgent, make logs rdf-data-shapes
19:32:36 <Arnaud> RRSAgent, bye
19:32:36 <RRSAgent> I see no action items