RDF Data Shapes Working Group Teleconference

<Arnaud> jose, are you joining the call?

<Labra> yes

<Arnaud> scribe: TallTed

<scribe> scribenick: TallTed

Admin

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

<aryman> _1

<aryman> +1

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

Disposal of Raised Issues

issue-69?

<trackbot> issue-69 -- status of rdf:langString values with xsd:string datatype -- raised

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

issue-70?

<trackbot> issue-70 -- special treatment of blank node types -- raised

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

issue-71?

<trackbot> issue-71 -- SHACL Endpoint Protocol -- raised

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

<Arnaud> PROPOSED: Open raised issues: ISSUE-69: status of rdf:langString values with xsd:string datatype, ISSUE-70: special treatment of blank node types, ISSUE-71: SHACL Endpoint Protocol

<Arnaud> PROPOSED: Open raised issues: ISSUE-69: status of rdf:langString values with xsd:string datatype, ISSUE-70: special treatment of blank node types, ISSUE-71: SHACL Endpoint Protocol

<hknublau> +1

<pfps> Apologies, I lost track of the time

<pfps> +1

<aryman> +1

+1

<ericP> +!

<ericP> +1

<kcoyle> +1

RESOLUTION: Open raised issues: ISSUE-69: status of rdf:langString values with xsd:string datatype, ISSUE-70: special treatment of blank node types, ISSUE-71: SHACL Endpoint Protocol

issue;72?

<Arnaud> issue-72

<trackbot> issue-72 -- Qualified Cardinality Restrictions -- raised

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

<Arnaud> PROPOSED: Open ISSUE-72: Qualified Cardinality Restrictions

<aryman> +1

<ericP> +1

{1}

+1

<kcoyle> +1

<hknublau> +1

<hsolbrig> +1

<Labra> +1

pfps: when did we agree that Core SHACL would fully handle ShEx?

ericP: that's roughly how I remember things...

<pfps> I don't remember an agreement that the core would cover ShEx.

[chatter about [citation needed] ... issue text being edited]

<pfps> I'm also not sure that QCRs are in ShEx.

<pfps> +1 with the part before 1) striken

<aryman> +1

+1

RESOLUTION: Open ISSUE-72: Qualified Cardinality Restrictions

ISSUE-1: What inferencing can or must be used?

<Arnaud> PROPOSED: SHACL should include a property sh:sparqlEntailment that can be used to specify a required inferencing level for each SPARQL query, as described in http://w3c.github.io/data-shapes/shacl/#sparql-entailment, per Holger's email

<hknublau> +q

<Zakim> pfps, you wanted to strike the SPARQL part

<aryman> suggest just sh:entailment

aryman: SPARQL defines a number of URIs for entailment, but the concept of entailment is not tied to SPARQL, so just strike SPARQL from the proposal and it should work...

pfps: concurs

<Arnaud> darn, my call dropped

hknublau: I think entailment needs to be tied to the language in play, using a Javascript extension may not need/want entailment while using a SPARQL extension may

aryman: valid point; application (or not) of entailment is related to how a query is phrased...
... one property should be sufficient, with a way to tie the given entailment to a given extension/query/subquery

pfps: concurs

hknublau: I don't see how this would be made to work...

<pfps> In my view the basic idea is what inference is going to happen in the background, i.e., what the execution engine doesn't have to do.

kcoyle: I see two entirely different points of view. 1 - SHACL expresses requirements that processor must satisfy ; 2 - SHACL says how those requirements will be satisfied

<aryman> we need to introduce one node per implementation of the extension, attach the query string and the entailment as properties to that node

<hknublau> That’s messing up the syntax.

<hknublau> Sure, JS engines may also rely on entailment.

pfps: I see no reason that Javascript couldn't apply the same (SPARQL) entailment as SPARQL

<Zakim> pfps, you wanted to ask about the core as well

<hknublau> +q

pfps: the other thing about making this SPARQL-specific is it seems to be external to core

<Arnaud> PROPOSED: SHACL should include a property sh:entailment that can be used to specify a required inferencing level

<kcoyle> +1

<pfps> +1

hknublau: design is that sparqlEntailment is attached to something (shape or query), so it's external to core anyway

<hsolbrig> +1

<aryman> +1

<Labra> 0

<pfps> +1 assuming that the property is global; -1 if local

hknublau: fine to take it as argument to engine, and if it can't be handled, then fatal error...

<hknublau> +q

aryman: it seems it has to be tied to the template

<pfps> Is there any SPARQL implementation that could support a local entailment regime?

hknublau: implemented a prototype that handled this...
... it does carry a performance penalty
... basically forward chaining into a temporary graph

aryman: what about a template designed with some assumption of entailment, which template gets reused without knowing about that assumption. how can the entailment be attached to the template

<pfps> I think that template reuse is a minor concern here.

<hknublau> +q

<aryman> I assume a global property would be on the shape

<pfps> I thought that the proposal on the floor was the global one.

hknublau: I'd like to see pfps's formulated proposal, including where it would be attached -- shape, graph, etc.

Arnaud: is it controlling? condition for execution? something else?

<pfps> Either as an argument to the engine or something in the control graph.

<Arnaud> PROPOSED: SHACL should include a global property sh:sentailment attached to a shape that can be used to specify a required inferencing level

aryman: let's pick simplest first step: global property attached to the shape

pfps: there seems to be a disconnect here. property on shape is a local property. global property would apply to entire control graph, or be argument to the engine...

<hknublau> +q

[discussion of some details]

<pfps> the idea is to have a property on the shape graph itself, using an identifier for the graph as the subject

<hknublau> Proposal: SHACL includes a proerty sh:entailment that can be set on the shapes graph to ensure that a certain entailment regime is activated on the dataset.

<aryman> +1

<hknublau> +1

+1

<pfps> +1

<hsolbrig> +1

<Labra> +0.5

<ericP> 0

<kcoyle> +1

RESOLUTION: SHACL includes a proerty sh:entailment that can be set on the shapes graph to ensure that a certain entailment regime is activated on the dataset.

<Arnaud> PROPOSED: sh:valueType must also match subclasses, with its SPARQL implementation using rdfs:subClassOf* as described in http://w3c.github.io/data-shapes/shacl/#sparql-AbstractValueTypePropertyConstraint

Arnaud: continuing with hknublau's proposal on ISSUE-1...

<Zakim> pfps, you wanted to say that this might be preempted by the previous resolution

<pfps> I feel that this half-way entailment is not something that should be in SHACL.

<Arnaud> PROPOSED: sh:valueClass must also match subclasses, with its SPARQL implementation using rdfs:subClassOf* as described in http://w3c.github.io/data-shapes/shacl/#sparql-AbstractValueTypePropertyConstraint

aryman: pragmatically we know that entailment is supported differently and incompletely, so this may serve users who don't need a full regime but do need this part...

<hknublau> +1

<aryman> +1

+1

<pfps> -0.5

<kcoyle> +1

<ericP> 0

RESOLUTION: sh:valueClass must also match subclasses, with its SPARQL implementation using rdfs:subClassOf* as described in http://w3c.github.io/data-shapes/shacl/#sparql-AbstractValueTypePropertyConstraint

<Labra> 0

Arnaud: continuing...

<Arnaud> PROPOSED: SHACL shall include another property sh:directValueType that only matches the directly asserted types (for OSLC use case), per Holger's email

aryman: restates his email comment... to change sh:directValueType to sh:valueType to match OSLC

<aryman> prefer to use sh:valueType

<Zakim> pfps, you wanted to ask what "directly asserted types" means

pfps: does "directly asserted" mean "what was typed by a monkey when the data was entered", "what went into the triple store", "what the triple store is serving up"?

aryman: it's a triple in the graph

pfps: so the result of any entailment... so "directly asserted" seems a misnomer

<aryman> should say it matches ?focusNode rdf:type ?type

<hknublau> +q

hknublau: valueType is also used in SPIN, with different meaning, so a different term should be used here for OSLC concerns

<Arnaud> PROPOSED: SHACL shall include another property sh:directValueType that matches ?focusNode rdf:type ?type (for OSLC use case)

<hknublau> Or: valueRDFType

pfps: "direct" is only OK if we add a paragraph to make explicit that this is post-entailment

<hknublau> +1 to sh:directValueType

<ericP> prposed "ar_dee_eff_colon_type"

<Arnaud> PROPOSED: SHACL shall include another property sh:directValueType that matches ?focusNode rdf:type ?type (for OSLC use case)

<aryman> +1

<hknublau> +1

+1

<hknublau> lol

<hsolbrig> +1

<kcoyle> +1 and I like Ted's suggestion

<Labra> +1 I would prefer valueType

<ericP> +1

RESOLUTION: SHACL shall include another property sh:directValueType that matches ?focusNode rdf:type ?type (for OSLC use case)

Arnaud: on to #4 of 5...

<Arnaud> PROPOSED: sh:scopeClass must also include instances of subclasses, with its SPARQL implementation using rdfs:subClassOf*

<aryman> +1

<hknublau> +1

+1

pfps: I don't think this is a correct statement... what happens in other [non-SPARQL, e.g., Javascript] implementations? do they do real subClass?

<aryman> the path is rdf:type/rdfs:subClassOf*

aryman: this is the same as we just talked about for sh:valueClass

pfps: yes, and this comment applies to that as well... SPARQL uses subClassOf*, but other implementations do what?
... both should be rewritten to remove SPARQL specificity

<hknublau> +q

<pfps> PROPOSED: sh:scopeClass must also include nodes with an rdf:type link to nodes connected to the class via the transitive closure of rdfs:subClassOf

<aryman> +1

<hknublau> +1

<hsolbrig> +1

+1

<pfps> -0.5

<Labra> 0

<kcoyle> +1

<ericP> 0

RESOLUTION: sh:scopeClass must also include nodes with an rdf:type link to nodes connected to the class via the transitive closure of rdfs:subClassOf

PROPOSED: (revising earlier resolution) sh:valueClass must also include nodes with an rdf:type link to nodes connected to the class via the transitive closure of rdfs:subClassOf

<pfps> nevermind: sh:valueClass must also match subclasses, i.e., nodes with a type that is an rdfs:subClassOf* of the class

<pfps> -0.5

+1

<kcoyle> +1

<aryman> +1

<hknublau> +1

<hsolbrig> +1

<Labra> 0

RESOLUTION: (revising earlier resolution) sh:valueClass must also include nodes with an rdf:type link to nodes connected to the class via the transitive closure of rdfs:subClassOf

<Arnaud> PROPOSED: SHACL shall include a high-level mechanism to express the scope of direct instances

aryman: I don't understand this one... what is a "direct instance"?

<pfps> I don't understand what this is for.

<pfps> So this is sh:scopeDirectType

<aryman> sh:directScopeType

hknublau: this is to apply a constraint only to direct members of a Class, not members of its subClasses

<aryman> like sh:directValueType

<Arnaud> PROPOSED: SHACL shall include a high-level mechanism, a la sh:scopeDirectType, to express the scope of direct instances

<hknublau> -1

<hknublau> +q

<pfps> -0.5

hknublau: this is a rare case, so I don't think it needs be implemented as core level element

<Arnaud> PROPOSED: SHACL shall include a high-level mechanism, functionally equivalent to what would be called sh:directScopeType, to express the scope of direct instances

<hknublau> +1

<aryman> +1

+1

<kcoyle> +1

<hknublau> +q

<pfps> Every language construct has its costs aside from the implementation code.

<Labra> 0

<pfps> Would a scoping construct like "given a property and object scope on nodes where there is a <n,property,object> triple"

<pfps> ... satisfy this?

<pfps> -0.5

<hknublau> +q

RESOLUTION: SHACL shall include a high-level mechanism, functionally equivalent to what would be called sh:directScopeType, to express the scope of direct instances

<Arnaud> PROPOSED: Close ISSUE-1, based on previous resolutions

<hknublau> +1

<aryman> +1

+1

<Labra> +1

<pfps> +1

<kcoyle> +1

RESOLUTION: Close ISSUE-1, based on previous resolutions

ISSUE-47: Can SPARQL-based constraints access the shape graph, and how?

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

<hknublau> +q

<Arnaud> trackbot, end meeting