RDF Data Shapes Working Group Teleconference

<kcoyle> do we have a scribe?

<Arnaud> scribe: jamsden

Admin

Arnaud: Mark Hedley joined the meeting today as an observer, in the process of joining the WG

Markh: 3 years involved in metadata specifications, metadata used for international exchange of linked data.
... Looking at validation of instances of metadata, exploring shapes as a means of specifications of descriptions that can be used for constraints, and apply to existing work

<Arnaud> PROPOSED: Approve minutes of the 24 March 2016 Telecon: http://www.w3.org/2016/03/24-shapes-minutes.html

<pfps> the minutes are a bit sparse, but cover the bases

RESOLUTION: Approve minutes of the 24 March 2016 Telecon: http://www.w3.org/2016/03/24-shapes-minutes.html

Disposal of Raised Issue

Arnaud: issue raised with lack of consistency in use of technology especially related to SPARQL and RDFS/OWL. Primarily editorial.

<Arnaud> PROPOSED: Open ISSUE-142: loose terminology

<kcoyle> +1

<pfps> +1

+1

<Dimitris> +1

<TallTed> +1

<pfps> This issue arose from my reading of section 6 of the document, which needs significant work.

RESOLUTION: Open ISSUE-142: loose terminology

Arnaud: resolutions are provisional until approval of the minutes in the next meeting.

ISSUE-93 - engine / language

<TallTed> Issue-93?

<trackbot> Issue-93 -- SHACL engine vs. SHACL instance requirements -- open

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

Arnaud: Issue describes SHACL as a language and its semantics. And also talks about an engine that mixes implementation with vocabulary and meaning.

kcoyle: suggests we re-read the document to explore the use of the proposed new language

pfps: agree fresh eyes would be good. Still mixing of what the language is and what a conformant engine must to.
... Not just a matter of looking for engine and making changes, might be more organizational
... Discuss the language separately from what "conformance levels" implementations might need to implement for interoperability

Scribe can't hear Dimitris

<pfps> It looks as if there has been some work to change SHACL engine to SHACL validation engine.

<pfps> dimitris: there is a core and extension section which makes teasing out the engine stuff harder.

semantics of language is sometime commingled with what a conformant engine must do

<pfps> so - "Here is SHACL core. Here is SHACL extension. SHACL validation engines must do X"

jamsden: separate language definition and semantics organized as capabilities that can then be included in different conformance levels implementations should support

<kcoyle> Dmitris, can you point to the exact section? Editor's draft?

<Dimitris> http://w3c.github.io/data-shapes/shacl/#validation

<kcoyle> thanks

Dimitris: requests that we review the document and provide feedback in the context of this issue
... Do we want to agree on the language for the definition of SHACL in the email list?

<Dimitris> mainly sections 2 and section 4

<Dimitris> http://w3c.github.io/data-shapes/shacl/#terms

<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Glossary

kcoyle: can we agree on the definition of and common language for what SHACL is? Then use this as a means of normalizing the spec?

Arnaud: might be useful to take a look at the glossary and terms, using the links above.
... Editors should make sure the terms are defined and used consistently, use the group to raise challenges and and clarify terms and their use.

<pfps> At least there is a document that provides a firm basis for the official RDF and RDFS terminology, including resource, node, property, etc.

<Zakim> ericP, you wanted to describe XML Schema approach

ericP: turtle uses a classification of documents, SPARQL something similar, provde a template for defining a W3C language.

XML Schema went further: rules for parsing, rules for validation, these provide models that could be used for SHACL.

ISSUE-99 special cases

Anaud: peter made a proposal and holger agreed, what is left to close this?

pfps: issue was resolve, but morphed to 99.5 to have something else for lists, sh:list - the value is the head of a list whose members are validated by the shape
... tricky to get right. Could be too complicated to address, or SHACL should provide a construct that address is

<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-99:_special_cases

pfps: there are currently 6 proposals, many of which do not have concensus. One gets rid of the special cases (this was done). Others all have to do with whether to have an sh:list construct.

Arnaud: could close issue-99 and possibly introduce a new issue/construct for sh:list in order to focus on that issue.

pfps: issue-46 was an issue for lists, closed with a lot of discussion. Could reopen this issue if we decide to revisit sh:lists

Arnaud: this was about requirements, closed because we added the requirements
... Agreed on the requirements, but not the solution.

<pfps> issue-119

<trackbot> issue-119 -- Defining constraints on (values of) rdf:Lists -- closed

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

pfps: issue-119 also addresses this issue and has been closed.

Arnaud: should close issue-99 and if anyone has specific interest in sh:list proposals to take this forward, could reopen 119 and close with a new proposal

<pfps> +1

+1

<Arnaud> PROPOSED: Close ISSUE-99, issue has been addressed, related proposals on handling of rdf:List should be made related to ISSUE-119, which would then need to be re-opened

<pfps> +1

<Dimitris> +1

+1

<kcoyle> +1

<TallTed> +1

<ericP> +1

RESOLUTION: Close ISSUE-99, issue has been addressed, related proposals on handling of rdf:List should be made related to ISSUE-119, which would then need to be re-opened

ISSUE-80 Scheme URIs

Arnaud: this is something that can already been done, and this is a convenience, asking Eric to see if the convenience has sufficient value to include

<Arnaud> issue-80

<trackbot> issue-80 -- Constraint to limit IRIs against scheme/namespace, possibly with dereferencing -- open

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

Arnaud: close action-36. the change doesn't seem that great

pfps: more or less agrees
... "as sugar its not very sweet"

<pfps> the other advantage of new syntax is that it can use curies where pattern cannot

kcoyle: worth it to her. doing it with patterns could be helpful. sh:stem makes it more specific, easier for more casual users.

<pfps> I don't see why not.

can someone summarize the discussion for the scribe?

<pfps> the point was whether to have this construct have an implicit disjunction somehow, either along with the current top-level disjunction (which would be new) or like in sh:classIn'

Arnaud: be sure everyone has the information needed to assess the issue, postpoine to next week?
... Can be done with sh:pattern, but may occur often enough to justify specific supporting syntax.

<Arnaud> STRAWPOLL: add support sh:stem per Eric's proposal

<pfps> 0

<Dimitris> 0

<TallTed> +0.25

<kcoyle> +1

<ericP> +.75

0 - I don't think the problem in the issue is well enough defined to assess the proposal

<Dimitris> DC Profiles have a related property "Value Encoding Scheme URI"

kcoyle: data refers to other data sources/lists, and these URIs need to be supported, constrain the URLs in the graph. Identfy an external force in a URI stem

ericP: clinical space, codes from different nomenclatures,

ISSUE-105: define prefixes

<Dimitris> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-105:_Defined_prefixes

Arnaud: holger added a proposal, but there was no discussion.

<pfps> New readers should beware of editorializing on the proposals page. Any WG member can put anything there.

https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-105:_Defined_prefixes

pfps: SHACL talkes about the namespaces of an RDF graph, but RDF doesn't have this except for in syntaxes. SHACL could internalize these prefixes, it needs to do something to support them

<pfps> the problem is how to get this to happen in some reasonable fashion

how is SHACL extension mechanism who want to write the SPARQL and don't want to have to write all the PREFIX definitions

kcoyle: what have other languages done

pfps: nothing, they don't need to do it. SPARQL isn't generating turtle docments, working with an RDF graph, this is only concerning the external syntax.

SHACL extension mechanism is writen to create SPARQL fragments that require the prefixes

TallTed: definition says we are starting wtih two graphs (not turtle or any specific syntax for the graph). Graphs don't have prefixes. The graphs might be serialized with prefixes, but this doesn't need to be addressed in SHACL

<pfps> the SPARQL extensinon needs to generate SPARQL documents and these may include curies and the prefix declarations then need to be part of the document

Dimitris: write extension mechanisms, sometimes convenient to use prefixes, in order to create a valid SPARQL query.

There could be many related queries that all need the same prefixes, where would these common prefixes defined?

Arnaud: issues with mixing information from different layers (representation vs actual graph).

<Zakim> ericP, you wanted to note the exception of SPIN

<pfps> So, is SELECT $this ($this AS ?subject) $predicate (?value AS ?object)

<pfps> WHERE {

<pfps> $this $predicate ?value .

<pfps> FILTER (isLiteral(?value) || NOT EXISTS {

<pfps> GRAPH $shapesGraph {

<pfps> $classIn (rdf:rest*)/rdf:first ?class .

<pfps> }

<pfps> FILTER NOT EXISTS { ?value rdf:type/rdfs:subClassOf* ?class }

<pfps> })

<pfps> }

<pfps> suitable as a query template in SHACL?

ericP: say extension that aren't SPARQL but something that has prebound extensions already defined. Betterh than having the SPARQL have access to prefixes in some turtle document which may not be accessible

<TallTed> so we're extending SPARQL now?

<pfps> Not really. The "string" sent to the SPARQL query engine would have prefix declarations added to the beginning.

<pfps> There are other, more important extensions to SPARQL that are needed in the current setup.

<Dimitris> http://dbpedia.org/sparql?nsdecl

Not putting SHACL into a SPARQL engine, so not extending SPARQL.

<pfps> My understanding is that the current design needs SHACL-in-SPARQL.

pfps: SHACL document contains lots of things that look like SPARQL queries that could not be directly executed. Missing the prefix declarations requried to parse them.
... Something needs to be done to provide the prefixes before these fragments are submitted to a SPARQL processor.
... prefix definitions can be included in SPARQL. adding the right prefix definitions should not be an issue.

<ericP> prefix and base decls in the SPARQL 1.1 grammar

pfps: handling them outside the SPARQL opens the possibilit of the prefixes not being properly or consistently defined.

holger wanted to be able to define the prefixes in one place in the SHACL extensions, and have them implicitly applied to SPARQL in the extensions.

<Arnaud> trackbot, end meeting