Re: Core or Lite?

On 3/24/2015 15:17, Arnaud Le Hors wrote:
> Holger,
> What would constitute the "extension mechanism" in your view then?

The macro facility could be regarded as an extension mechanism for the 
core vocabulary. Another extension mechanism is the ability to use other 
languages such as shx:javaScript. But writing complex queries (e.g. 
using SPARQL) is not an extension mechanism. Also, using pre-defined 
macros from a 3rd party template library is also not an extension. So 
the headline of that Part 2 should reflect this differently. That was 
all I wanted to point out.

>
> I have to point out that Arthur's suggestion happens to be very much 
> in line with what the charter calls for:
>
> *An RDF vocabulary*, such as Resource Shapes 2.0, for expressing these 
> shapes in RDF triples, so they can be stored, queried, analyzed, and 
> manipulated with normal RDF tools, with some extensibility mechanism 
> for complex use cases.
>
> I don't think it helps to ignore that and try to force people into 
> considering what was meant to be an "extensibility mechanism for 
> complex use cases" the "completely normal use of SHACL".

I stick to my statement that it is a completely normal use of SHACL to 
include SPARQL queries. It is also completely normal for OWL DL users to 
rely on features outside of OWL Lite. In the draft, SPARQL is part of 
the official spec. For a large class of users, what you call the 
"extensibility mechanism" will even be the main feature of SHACL. This 
includes people who currently use OWL and just want to use SPARQL for 
the bits that OWL cannot express. This is how TQ customers have operated 
for many years and is also the least disruptive path to adoption if we 
want SHACL to succeed with current semantic web people.

What we have right now in the WG is that some people believe they don't 
really need SPARQL support, and that the core features are sufficient 
for most use cases. That's good for them, although not backed by much 
empirical evidence. At this stage we have no idea which features will be 
most widely used. Claiming that feature 1 is more important than feature 
2  (and call feature 2 just an "extension") is premature and makes it 
more difficult for the supporters of feature 2 to get heard.

The wording in the Charter was in retrospect unfortunate but it was 
difficult to clarify all these nuances in a single short sub-sentence. 
Back then I have been very clear that I will object to any attempts to 
marginalize the SPARQL support, and I will continue to do this. I hope 
the group respects the point of view of the SPARQL camp in the same way 
that we all respect the point of view of those who don't need really 
SPARQL support. My draft supports both view points.

Regards,
Holger