Re: Core or Lite?

Arnaud,

I didn¹t say that 80% of all use cases can be addressed declaratively. I
said that in our experience:
* Pretty much everyone needs some custom built templates
* Some can use 80% of pre-bult declarative constructs and 20% of custom
built templates
* For other users, percentage of ³custom" is much higher and can be over 50%
* There is no common 80% and 20% percent across all users ­ which of the
declarative prebuilt templates/statements each uses varies across different
users, how much and what exactly they need to custom build also varies
Hope this clarifies.

Irene

From:  Arnaud Le Hors <lehors@us.ibm.com>
Date:  Tuesday, March 24, 2015 at 1:42 PM
To:  Richard Cyganiak <richard@cyganiak.de>
Cc:  "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Subject:  Re: Core or Lite?
Resent-From:  <public-data-shapes-wg@w3.org>
Resent-Date:  Tue, 24 Mar 2015 17:48:02 +0000

I totally agree with everything you said here Richard and actually don't
know of anyone disagreeing. If anyone does I'd like to hear it.

I think the contention is over the place given to the extension mechanism
and specifically whether it is the foundation on which everything is built
and depends. By your own words, and in line with Irene's input that 80% of
use cases can be addressed declaratively, the "expressive fallback" should
just be that - a fallback - and not the main foundation of the spec. I think
this is what's getting some people to push back on Holger's proposal.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM
Software Group


Richard Cyganiak <richard@cyganiak.de> wrote on 03/24/2015 10:19:13 AM:

> From: Richard Cyganiak <richard@cyganiak.de>
> To: Arnaud Le Hors/Cupertino/IBM@IBMUS
> Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
> Date: 03/24/2015 10:21 AM
> Subject: Re: Core or Lite?
> 
> The workshop report says that ³SPARQL plays a prominent role in how
> people tackle the validation problem today² and that ³constraints
> checking can be performed using SPARQL quite effectively².
> 
> However, it also says that ³SPARQL queries cannot easily be
> inspected and understood, either by human beings or by machines, to
> uncover the constraints that are to be respected², and therefore
> ³SPARQL does not constitute a complete solution². From this arises
> the need for a declarative approach to constraints, and this cannot
> be delivered by SPARQL alone.
> 
> Hence the consensus opinion that you quote: A declarative high-level
> vocabulary for the most common cases, with an ability to break out
> into something like SPARQL for the inevitable more complex cases
> that can¹t be handled by the declarative solution.
> 
> But it is clear from the workshop report that a declarative solution
> alone would not satisfy many of the workshop participants, and
> there¹s nothing in it to suggest that complex constraints on the
> level of SPARQL are uncommon or not typical.
> 
> We need both; the declarative vocabulary and the expressive
> fallback. Proposals that only address one (like Resource Shapes, and
> most of the descriptions of ShEx, and Peter¹s original CONSTRAINTS
> proposal) are insufficient to address the charter.
> 
> Best,
> Richard
> 
> 
> 
> > On 24 Mar 2015, at 15:51, Arnaud Le Hors <lehors@us.ibm.com> wrote:
> > 
> > I think we're touching on the very point of division in the group:
> whether writing complex queries using SPARQL is the normal/common
> case or not. From my point of view the workshop clearly didn't
> support that point of view and this is why the charter is written
> the way it is. 
> > 
> > Participants agreed that we should have a declarative mechanism a
> la OSLC Resource Shapes and, in recognition of the fact that there
> is only so much one can do that way, an extension mechanism should
> also be available to address complex cases which can't be handled
> declaratively. Here is how the report reads (http://www.w3.org/2012/
<http://www.w3.org/2012/>
> 12/rdf-val/report):
> > 
> > There was consensus on the need for
> > 1.        Declarative definition of the structure of a graph for
> validation and description.
> > 2.        Extensible to address specialized use cases.
> > 3.        A mechanism to associate descriptions with data.
> > 
> > Note that this doesn't mean that the extension mechanism is any
> less normative than the declarative one but it makes a difference as
> to whether the extension mechanism is the center piece (or as
> Richard put it "the most basic construct") or not.
> > --
> > Arnaud  Le Hors - Senior Technical Staff Member, Open Web
> Technologies - IBM Software Group
> > 
> > 
> > Arthur Ryman <arthur.ryman@gmail.com> wrote on 03/24/2015 05:50:14 AM:
> > 
> > > From: Arthur Ryman <arthur.ryman@gmail.com>
> > > To: Holger Knublauch <holger@topquadrant.com>
> > > Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
> > > Date: 03/24/2015 05:51 AM
> > > Subject: 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
> > > >
> > > 
>