Re: Core or Lite?

Michel,

We can¹t do this because 20% (which is just a rough number for some
proportion of customers) tends to be different for each customer and for
each new application/data model a customer may have. These are unique needs.
Further, there are customers that have 50%+ percent of custom.

Of the things that are pre-built what is being actually used by a given
customer also varies greatly. Cardinalities are popular. Value ranges, of
course. Some comparison/dependency between properties is common ­ if
property X is that, then property Y must be this. This could be all sort of
different thins ­ one must be less than another, if one exist, the other
needs to exist, if one is greater than something, the other must be less
than something and on and on.

Irene

From:  Michel Dumontier <michel.dumontier@stanford.edu>
Date:  Tuesday, March 24, 2015 at 12:29 PM
To:  Irene Polikoff <irene@topquadrant.com>
Cc:  Arnaud Le Hors <lehors@us.ibm.com>, RDF Data Shapes Working Group
<public-data-shapes-wg@w3.org>
Subject:  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
> <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
>>> > >
>> >