Re: Core or Lite?

Hi,
  It would be useful for you to tease out the 20% for us to better
understand the need, and to see whether we can standardize the functional
requirement.

m.

Michel Dumontier, PhD
Associate Professor of Medicine (Biomedical Informatics)
Stanford University
http://dumontierlab.com

On Tue, Mar 24, 2015 at 9:24 AM, Irene Polikoff <irene@topquadrant.com>
wrote:

> Majority of our customers end up needing to write some SPARQL-based
> templates for data validation and UI generation. The pre-built constructs
> may cover 80% of their use cases, but 20% still remains. And for some the
> pre-built constructs (and we ship a bit more than what is now in SHACL)
> cover less than 50%. We try to look for commonality and gradually include
> the most common ones as pre-built. But complete coverage is simply not
> possible. Each customer has some uniqueness. Being able to formally define
> their own templates has been pretty critical for these users. Some have
> talked about creating template exchanges where they could share with others.
>
> Over the last 10 years of working with customers that use RDF to stand up
> enterprise solutions, we have been in direct communication with hundreds if
> not thousands (some use our products without having any in depth
> interactions with us). These customers span many different industries –
> financial services, pharma and health care, energy, manufacturing,
> government and so on. I am not sure to what extent anyone else on the
> working group has had a similar breadth and depth of experience across the
> number of different customers, applications and industries.
>
> Many of these users have running enterprise systems and their needs are
> important. I believe the fact that the workshop did not receive this input
> shouldn't matter at this point. We are providing it today. Further, this
> working group has moved well beyond the information available during the
> workshop by collecting requirements over the last 6 months. Is there any
> reason we need to go back to the workshop when considering requirements?
>
> Irene
>
> From: Arnaud Le Hors <lehors@us.ibm.com>
> Date: Tuesday, March 24, 2015 at 11:51 AM
> To: <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 15:57:35 +0000
>
> 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/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
> > >
> >
>