Re: core remaining issues

On 6/01/2017 17:21, Dimitris Kontokostas wrote:
> Hello, according to my view these are the core remaining issues of SHACL.
> IMO, the WG should prioritise these over the other issues
>
> A) SPARQL related
> 68 - pre-binding not defined in SHACL spec 
> <https://www.w3.org/2014/data-shapes/track/issues/68>
> 170 - SPARQL specifies a different reading for exists and blank nodes 
> than needed for SHACL 
> <https://www.w3.org/2014/data-shapes/track/issues/170>
> 202 - Suggestion to remove pre-binding from core 
> <https://www.w3.org/2014/data-shapes/track/issues/202>
>
> 68 & 202 are related and 170 makes it a bit more difficult to define 
> pre-binding.
> We are at a very late stage and these are not fixed yet and this is 
> one of the reasons I advocate the splitting of core / full as I fear 
> these may drag down the whole of SHACL if we keep them together.
>
> With Peter's write up we have a core spec without any SPARQL 
> definition. We can still add the existing examples to make it more 
> user-friendly and core can easily remain unaffected
>
> In addition, I think that Full has very few issues because people were 
> focusing on core so far and no-one looked in full in detail as the 
> foundation (core) was (and still is) not ready.

Yes, fewer people looked at the SPARQL features, because the WG decided 
to spend all time on the Core. The (random) make up of the WG 
unfortunately included few people interested in the SPARQL aspects.

>
> proposal: Move sections 5 & 6 into a separate document and target it 
> for REC track as well.
> (this is orthogonal to making sections 7+ non-normative)

In terms of editing this is of course a possibility. We need to make 
sure though that the design remains consistent. Peter's draft has two 
notable absences: it neither talks about the extension mechanism nor 
does it include the TTL file (i.e. details of the metamodel). If you 
want to promote metamodel changes, you'd need to provide these. Two 
documents make it more likely that things don't fit together anymore.

>
> Agenda item: discuss the addition of a new editor to help
>
> comment: Ted and Andy suggested that the editors decide based on what 
> is easier. Splitting will require more work for sure but imo, the 
> sooner we do the splitting the more time we will have to make both 
> documents in a good shape
>
> B) Metamodel
> Issue 211 is re-opened and the sooner this is resolved the better.
> Proposal B1: Adopt a variation of Peter's suggestion as described 
> here: 
> https://www.w3.org/2014/data-shapes/wiki/index.php?title=Proposals#ISSUE-211:_Eliminate_property_constraints
> Proposal B2: Accept peter's proposal as is (without my variation)
>
> wrt (B2), one of the main reasons of my variation was to keep the UI 
> related properties for property-related shapes/constraints.
> However, a recent comment indicates that there are use cases for using 
> them with focus node constraints as well 
> https://lists.w3.org/Archives/Public/public-rdf-shapes/2017Jan/0000.html
> both have a +1 from me but I would now favour B2 over B1

The proposal includes dropping sh:property and thus changes the whole 
syntax significantly. Also, sh:property and sh:shape currently produce 
completely different results: sh:property includes all "nested" results 
as top-level results, while sh:shape only produces a single violation 
per node and thus allows implementations to stop after the first 
violation. I strongly believe that we need to keep both sh:shape and 
sh:property.

>
> C) sh:predicate / sh:path
> 217 - 
> https://www.w3.org/2014/data-shapes/wiki/index.php?title=Proposals#ISSUE-217:_Path_vs_predicate_clean_up
>
> Currently, sh:predicate is redundant, in all SHACL example (in the 
> spec or in the wild) we can just replace sh:predicate with sh:path and 
> nothing will change in the behaviour of the shapes.
> However, this is a very big burden on the spec that results in a lot 
> of prose

I disagree that this is a "very" big burden or "lot of prose". We could 
technically use a single property, but I don't think that sh:path would 
be a good name for such a merged property. In the vast majority of 
cases, its values will be simple predicate IRIs while sh:path is the 
exception. Does anyone have a better name?

We should not forget that we are designing a language here that will be 
used for many years. I don't think we should make design choices based 
on what currently looks attractive from a spec writing perspective if 
the outcome is a language that is no longer user friendly.

Holger


>
> proposal C: Delete sh:predicate and keep only sh:path since all 
> sh:predicate values can already be represented by sh:path
>
> comment 1: this is a core issue as it will affect existing syntax
> comment 2: This, in combination with (B) makes it  easy to identify 
> "property constraints" which was one of Holger's concern wrt 
> sh:property and the metamodel change
>
> Best regards,
> Dimitris
>
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia 
> Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org, 
> http://aligned-project.eu
> Homepage: http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>