This wiki has been archived and is now read-only.

Strawpoll On Approach

From RDF Data Shapes Working Group
Jump to: navigation, search

This page is dedicated to assessing the position of the WG members on two different possible approaches being proposed for the development of SHACL. Note that in both options being proposed, all documents are normative (i.e., REC) and required to fully addressed the deliverables set by the charter.

This is a followup to the strawpoll the WG had on its 12 March 2015 Telecon.

Reminder: This is a STRAWPOLL not a PROPOSAL, and as such it is not binding. However, it may inform the chair as to what PROPOSAL to make.


  • OPTION a) SHACL shall be made of a single document which includes everything - high-level language constructs + extension mechanism + semantics - with a set of profiles which define appropriate subsets
  • OPTION b) SHACL shall be made of several documents: one document which only defines the higher-level language constructs, and other documents which define the rest: extension mechanism and the semantics.


  • <add your response here as in "a:x b:y your_name" where x and y are one of -1, 0, and +1.>
  • a:+1 b:-1 Holger (TQ)
  • a:0 b:-1 pfps I don't think that either approach is ideal. I'm also not sure what "defines" is supposed to be.
  • a:+1 b:-1 Dean (WO)
  • a:+1 b:-0 Richard (I think that different audiences can be served better by a single document. Splitting would just create more work for the WG, is bad for extension users who now have to jump between two documents, and will be an editorial headache once we get to defining different profiles.)
  • a:+1 b:0 kcoyle (although other documents, like primer and tutorial may be needed)
  • a:+1 b:-0 Dimitris (I suggest we put an additional Appendix section next to SPARQL Appendixes where we can define the core vocabulary in semantics different from SPARQL)
  • a:+1 b:0 SSt (+1 to Karen's and Richard's comments)
  • a:-1 b:+1 Arthur (Comments)
  • a:-1, b:+1 Labra (Comments)
  • a:+1, b:-0.5 Tthibodeau (I am strongly inclined against the split, but I don't see it as entirely unworkable.)
  • a:-1, b:+1 michel (split in support of multiple implementations)
  • a:-1 b:+1 Anamitra (IBM)
    • Tthibodeau - I don't see anything about one document which prevents nor even discourages multiple implementations... Please clarify?