Proposed next steps (was: Re: core remaining issues)

A rewrite and split of the spec based on my three proposals above is
provided here:
 - https://jimkont.github.io/data-shapes/shacl/core.html
 - https://jimkont.github.io/data-shapes/shacl/sparql.html

I propose they are all accepted together with the above versions of the
spec.
if this is accepted by the WG I propose the following timeline

 - Add another editor to help with the workload (assigned at the same
meeting)
 - give 1-2 weeks time for the editors to prepare another Editor's draft(s)
 - publish next editor's draft by 18/01/2016 or 25/01/2016 asking thorough
evaluation by the community
 - Try to close all issues and target for CR after 2 weeks -> 08/02/2016

Status of the documents:
 - core is based on Peter's original proposal and is decoupled from SPARQL.
It needs some improvements in formatting and proof-reading but is in a very
good shape already.
 - sparql needs a bit more work but it needed it anyway. I renamed some
names, changed some text to align it  etc. but I kept the existing prose as
much as possible as it had some problems already.
 - wrt to the ttl files, the easiest way is to split them according to the
spec. I suggest the SPARQL spec uses the shs prefix. of course, both the
names and the prefix are open to suggestions.

Best,
Dimitris

On Fri, Jan 6, 2017 at 9:21 AM, Dimitris Kontokostas <
kontokostas@informatik.uni-leipzig.de> 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.
>
> 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?tit
> le=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=P
> roposals#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
>
>


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