- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sat, 17 Dec 2016 08:05:29 +1000
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Reflecting on the previous meeting, I was quite surprised that so many people in the WG seemed to favor splitting off the SPARQL-related bits of SHACL into a separate document. Although I did vote -1 on this, and others did too, there is potentially another intermediate solution that we did not fully discuss. From my experience, SPARQL-based constraints and constraint components (i.e. sections 5 and 6) are crucial and form an essential part of the value proposition and architecture of SHACL. However, the other features of SHACL Full: - Derived values constraints - SPARQL-based targets - SPARQL functions are fairly stand-alone and would be easy to modify. SPARQL functions in particular are invaluable in practice, but nothing in the definition of SHACL depends on them. SPARQL-based targets have been mentioned as replacement for the removal of filters, but I have not used them yet and in the interest of time, trade-offs need to be made. One option would be to make these features OPTIONAL and their definitions not normative. Is my understanding correct that this would take these features off the critical path, i.e. even if someone finds problems in their definition in the CR, we would not need to republish? This option would mean that we would not need to modify the document much, and those vendors that chose to implement them at least have shared semantics. Another option would be to move those features into a separate WG note. I would assume that we can still use the same namespace and keep their declarations in the TTL file. The effect would be similar to the first option, but it would be more difficult for the main document to point at these features (e.g. where targets are explained). OTOH, a separate non-normative note would be an opportunity to fold in SHACL rules (sh:rule) even if the WG wasn't chartered to do that. I welcome discussion on these ideas. Holger
Received on Friday, 16 December 2016 22:06:18 UTC