Re: multiple value shape?

I believe that for inclusion in Core, we need to assess what percentage of
users are likely to need/use the expression. If it is 70-80% of the users,
then it should definitely be in Core. Otherwise, it becomes more
questionable especially as it gets below 50% and lower.

There are things pretty much every single user/use case would need. To me,
this is what Core is about. There tends to be a lot of agreement about these
­ everyone agrees that they are needed.

Then, there are certain things some users find very important and they may
lobby for these strongly. But if this is not a majority of users or there is
uncertainty and a lot of guess work over how many would use them, such
expressions may be best left to the user defined extensions. They are still
supported, just not in a way that imposes them on all users and all
implementers.

As for QCRs, I remember excitement about them around the time OWL 2 was
developed. Some people thought they cared a lot about this feature. In the
end, if you look at the ontologies out there, very few use QCRs.

Irene Polikoff



From:  Holger Knublauch <holger@topquadrant.com>
Date:  Friday, May 29, 2015 at 10:05 PM
To:  <public-data-shapes-wg@w3.org>
Subject:  Re: multiple value shape?
Resent-From:  <public-data-shapes-wg@w3.org>
Resent-Date:  Sat, 30 May 2015 02:07:41 +0000

    
 
Folks, you both have important points and we all need to be careful what we
state here, to not give wrong impressions to the outside world.
 
 First we need a resolution on whether other languages than SPARQL can serve
as extension languages. I have opened
 
     https://www.w3.org/2014/data-shapes/track/issues/60
 
 for that purpose. Once we decide to do that, then I would like to take back
my statement that "SPARQL is always a fallback" and suggest the more general
"Extension languages such as SPARQL or JavaScript are always fallbacks".
This should cover the use cases that Arnaud talks about.
 
 I want to note however that we are on a slippery slope here, and we need to
be clear about the role of the Core Vocabulary. Stating that users cannot
use SPARQL features because not every platform supports them is extremely
dangerous, because it would lead to a situation similar to the "Don't leave
OWL DL" scaremongering. It would basically discourage people from using the
very power of SHACL only because *some* implementations don't want to
support SPARQL, or cannot support SPARQL. But these implementations may turn
out to be minorities. We cannot anticipate this yet, but discouraging SPARQL
use will serve as a self-fulfilling prophesy.
 
 The other dimension of the discussion is that the more features we add to
the Core language, the more complex it becomes for users and implementers.
In the end, it might become just as complex as SPARQL, and we have exactly
the same situation over again: many users wouldn't be able to use it (too
hard to learn), and not every implementation would support all SHACL Core
features. My answer to all this is that a flexible extension mechanism will
go a long way.
 
 On the political dimension, I also understand Arnaud's desire for the
SPARQL camp to listen to the ShEx camp, and make sure that their favorite
use cases such as Qualified Cardinality Restrictions can be expressed via
the core language (and thus the Compact Syntax). I am very open to this,
assuming we can agree on a realistic definition of QCRs. But at some stage
we need to stop adding features to the Core and let the extension mechanism
and the template libraries do their job. It is not our job to re-invent a
poor-man's variant of SPARQL or JavaScript and expect all vendors to
implement it, and all users to learn it. People already familar with SPARQL
will prefer SPARQL, and people already familiar with JavaScript will prefer
JavaScript.
 
 Thanks,
 Holger
 
 
 On 5/30/2015 1:32, Arnaud Le Hors wrote:
 
 
> "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> <mailto:pfpschneider@gmail.com>  wrote on 05/29/2015 07:57:34 AM:
>  
>>  > ...
>>>  > > Should be possible but not necessarily practical. -- Arnaud  Le Hors -
>>>  > > Senior Technical Staff Member, Open Web Technologies - IBM Software
>>>  > > Group
>>  > 
>>  > Possible, and thus available as a fallback.
>   
>  Sorry but I find this line of reasoning silly so I'm not going to answer any
> further. 
>  --
>  Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM
> Software Group
>   
>  
>