core remaining issues

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.

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)

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

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

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