RDF Data Shapes Working Group Teleconference

<simonstey> it's actually shapes

<scribe> scribe: aryman

Admin

<Arnaud> PROPOSED: Approve minutes of the 11 June Telecon: http://www.w3.org/2015/06/11-shapes-minutes.html

<pfps> minutes look fine

RESOLUTION: Approve minutes of the 11 June Telecon: http://www.w3.org/2015/06/11-shapes-minutes.html

Disposal of raised ISSUE-66

TallTed: asks for descriptive names for bugs

<Arnaud> issue-66

<trackbot> issue-66 -- bug in SHACL spec -- raised

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

<hknublau> Can we just open this and move on? We already had 10 minutes last time…

<TallTed> +1 open it! :-)

<Arnaud> PROPOSED: Open ISSUE-66: SHACL spec ill-founded due to non-convergence on data loops

pfps: changed title to "spec ill-founded due to non-convergence on data loops"

<simonstey> +1

<hknublau> +1

<Labra> +1

<pfps> +1

+1

<Dimitris> +1

<ericP> +1

<kcoyle> +1

RESOLUTION: Open ISSUE-66: SHACL spec ill-founded due to non-convergence on data loops

<Arnaud> ISSUE-68

<trackbot> ISSUE-68 -- pre-binding not defined in SHACL spec -- raised

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

<hknublau> +q

Disposal of raised ISSUE-68

<Arnaud> PROPOSED: Open ISSUE-68: pre-binding not defined in SHACL spec

+1

<ericP> +1

<hknublau> +1

<Dimitris> +1

<TallTed> +1

<pfps> +1

<Labra> +1

<kcoyle> +1

<simonstey> +1

RESOLUTION: Open ISSUE-68: pre-binding not defined in SHACL spec

<hsolbrig> +1

SHACL Formal Definition

<Arnaud> http://w3c.github.io/data-shapes/shacl-ref/

fyi, here is HTML generated from an RDFS Turtle vocab at IBM: https://jazz.net/wiki/bin/view/LinkedData/JazzProcessVocabulary

aryman: how was the doc generated?

hknublau: I used a TopBraid feature called SPARQL Web Pages (SWP)

<Zakim> pfps, you wanted to ask what "long term" is involved here

Arnaud: agree that we should have non-commercial tools

pfps: what long term maintenance issues are there?

aryman: we should automate the build chain as much as possible, e.g. to correct typos, improve text etc.

<Zakim> pfps, you wanted to ask what the scope of this document is supposed to be

Arnaud: what is the relation of the generated HTML to the other specs? which is normative?

<pfps> I don't think that the document is going to define the semantics of SHACL.

<Zakim> pfps, you wanted to talk about W3C publishing normative machine-readable documents

aryman: the Turtle vocab should be normative, published on the web, and serve up HTML as per W3C recommendations
... also we should have a normative SHACL document to describe SHACL documents, but probably need to augment that with normative prose

@ericP: avoid duplication of source, include generated HTML in hand-written HTML spec

pfps: expresses concern about W3C hosting things like DTDs due to serve load

@ericP: W3C rate-limits requests

pfps: What if SHACL can't fully describe SHACL?

I expect SHACL to describe syntax only, but possibly not even completely

<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.

hknublau: continue for now with the two documents 1) manual 2) generated, get rid of the appendix

<pfps> The current document provides a lot of stuff that looks like semantics - what status does this part of the document have?

@pfps we still need the semantics written down precisely somewhere - if that can be in the comments of the vocab, then fine

<hknublau> Yes to improving the rdfs:comments

suggest we look at integrating the HTML generation into ReSpec, c.f. work done by Steve Speicher for OSLC Shapes

<pfps> Well then what is the status of the comments?

@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

<pfps> Even if the redundancies are pulled out of the other document, the remaining definitional parts will still be scattered.

<hknublau> +q

ISSUE-1

hknublau: we can split this issue up into a few proposals
... We cannot rely on inferencing being available, so we need to do some in the SHACL engine
... Main use case is for subclass inferencing in valueType and classScope, i.e. use rdf:type;rdfs:subClassOf*
... But in OSLC Shapes there is no subclass inferencing

pfps: bad idea to just to rdfs:subClassOf*

<pfps> I'm against implementing yet another kind of inference.

pfps: SHACL should repect RDFS semantics

<simonstey> +q

<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.

I suggest we avoid claiming "inferencing" and simply provide pairs of vocab terms, one for rdf:type and another for rdf:type;rdfs:subClassOf*

simonstey: the language will get too complicated if we introduce many variants of paths (I want property paths too!)

<Dimitris> +q

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

Dimitris: agree with Holger and Arthur that the subclass use case is very important

<pfps> I'm definitely saying that RDFS inferencing is my preferred solution.

<simonstey> +1 to holger's point

hknublau: "do nothing" is not realistic since the use of ontologies raises expectations for subclass paths
... RDFS inferencing is not implemented uniformly

pfps: Why does the subclass portion of RDFS get preferential treatment?

<pfps> it's not just rdfs:domain and rdfs:range, it's also subproperties of rdfs:subClassOf

hknublau: rdfs:domain and rdfs:range are not important for SHACL, but rdfs:subClassOf is

hsolbrig: We should rely on SPARQL enpoints to do the inferencing

<pfps> rdfs:subPropertyOf is also important, I think

<hknublau> Straw poll at least?

Arnaud: more people should propose solutions to this ISSUE

<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)

<hsolbrig> +1 to Arthur's suggestion

<hknublau> Yes this property already exists in the proposal, sh:sparqlEntailment

<hknublau> but this is for custom SPARQL queries only.

<pfps> I thought that we were moving on

<ericP> +1 to arthur's approach

<ericP> which i read as consistent with harold's proposal

ISSUE-47

<Arnaud> issue-47

<trackbot> issue-47 -- Can SPARQL-based constraints access the shape graph, and how? -- open

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

<Dimitris> +q

Dimitris: OK if used just by core language. Are there good use cases for extensions to access the shape graph?

<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

@pfps - the core uses it for closed shapes

<hknublau> +q

<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

@pfps, the semantics of the core language is defined by SPARQL so it affects what SPARQL is generated

<pfps> is the semantics of the core language defined by SPARQL? is that in the current document?

hknublau: this issue affects how SPARQL is generated

pfps: Why does the core need this?

<hknublau> +q

pfps: Access to the shape graph rules out important use cases, e.g. SPARQL endpoints, services

<pfps> I'm saying that the core doesn't need this

<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

hknublau: the current implementation provides the shape graph as a named graph via "shapeGraph" variable

<Dimitris> +q

hknublau: the engine should fail gracefully, i.e. if the shapeGraph is not available then fail

pfps: AFAIK only recursion requires access to the shapeGraph

<pfps> and other constructs can be effectively implemented wihtout such access

Dimitris: I don't want to limit the whole language if the shapeGraph is not available in all use cases

<hknublau> My proposal is in the spec, plus have a separate document for SPARQL endpoints.

<hknublau> +q

pfps: Current spec is written assuming that the shapeGraph is available in many case. My proposal did not require the shapeGraph.

<Dimitris> my proposal is that if there are no use cases, disable access outside of the core language

hknublau: The implementations can avoid the shapeGraph in the cases where it is not needed. The use of the shapeGraph makes the spec simpler.

Arnaud: members should review the proposals

<Arnaud> trackbot, end meeting