Re: Core or Lite?

Holger,

All aspects of SHACL that are described by the spec are normal in the
sense that they define compliant behavior. You seem to be implying
that only Part 1 is normal. I don't understand what is gained by this
use of the term "normal".

I'd also like to clarify that I think we only need one RDF namespace.
Part 1 defines some of the terms and Part 2 defines the rest of the
terms.

If we are going to use the term "normal", let's agree on the meaning.
One meaning is say that the largest user group is the "normal" one. If
that is the case then we have clear feedback that the majority of
users will want a high-level vocabulary for expressing common
constraints. A smaller, more advanced, set of users will write
constraints in SPARQL, JS, ShEx, etc.

-- Arthur





On Tue, Mar 24, 2015 at 1:50 AM, Holger Knublauch
<holger@topquadrant.com> wrote:
> 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
>

Received on Tuesday, 24 March 2015 12:50:41 UTC