Re: Proposed change to the charter, section 4. Deliverables, Recommendation Track

Dimitris,

You wrote: "@Arthur, Eric, Jose
It would be great if you could shed some light in the actual differences 
between ShEx and Shapes (besides the syntax and the property group 
extensions by ShEx)"

Shapes is a high-level RDF vocabulary that let's you assert many commonly 
occurring constraints such as occurrence and range. It is not a 
programming language. It is not extensible. It does not have a formal 
semantics. It has no extension mechansim. It is aimed at developers who 
understand similar constraints in OO, database, etc. It is also intended 
to be a source of metadata for a variety of other tools such as query 
builders, form builders, and documentation generators.

ShEx is a programming language that can express the constraints defined by 
Shapes, and many others since you can write down arbitrarily complex ShEx 
expressions. It is complementary to Shapes in that it let's you express 
more constraints. The price you pay for the increased expressiveness is 
that you need to understand a new programming language.

BTW, there was some question of what is meant by a high-level RDF 
vocabulary. This is of course subjective, however Shapes, RDFS and OWL are 
high-level since they introduce terms for high-level concepts rather then 
define them using rules that use terms for lower level concepts. For 
example, the SPIN vocabulary for expressing SPARQL as RDF is a low-level 
vocabulary.

Regards, 
___________________________________________________________________________
Arthur Ryman, PhD

Chief Data Officer, Rational
Chief Architect, Portfolio & Strategy Management
Distinguished Engineer | Master Inventor | Academy of Technology

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:   Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
To:     Holger Knublauch <holger@topquadrant.com>, 
Cc:     "public-rdf-sha." <public-rdf-shapes@w3.org>
Date:   08/03/2014 04:32 AM
Subject:        Re: Proposed change to the charter, section 4. 
Deliverables,  Recommendation Track






On Sun, Aug 3, 2014 at 9:21 AM, Holger Knublauch <holger@topquadrant.com> 
wrote:
A pragmatic proposal: I do believe there is consensus that this WG can 
potentially create some useful and relevant output that could lead to 
broader use cases for semantic web technology as a whole. There are 
several proposals on the table that are potentially complementary to each 
other. Assuming there are enough people who actually sign up for the work, 
why not produce multiple deliverables that cover more use cases?

1) Shapes + SPIN, with an explicit mandate to have semantics that are 
executable by SPARQL engines, from day one. The alternative would be ShEx 
and this could be figured out in the beginning of the WG. This deliverable 
would be like an extension to SPARQL.

plus

2) OWL closed world semantics, so that existing OWL ontologies can be 
reused. This deliverable would basically be an "appendix" to the OWL 2 
spec.

This would allow the interest groups to stay on their home turf without 
blocking each other, because blocking each other would be the worst 
outcome of all. I see no technical difficulties with such as stack, 
because these technologies are complementary to each other: we use OWL 
closed world + SPIN all the time, and it works well in practice. In fact I 
believe both specifications have a good and stable starting point so that 
we could proceed with the process very swiftly.

>From my POV it would be more interesting to do a comparison in action by 
implementing PROV Constraints (http://www.w3.org/TR/prov-constraints/) in 
all proposed solutions (ShEx, SPIN, Shapes, ICV, OWL).
I think PROV is a nice use case because it has a moderate complexity and 
can reveal weaknesses / strengths in terms of expressivity, readability & 
compactness. A plus would be to capture the constraints of the PROV 
ontology in CWA.
Paul Groth already made an attempt to port these constraints in SPIN [1] 
but I am not aware if these are complete or optimized. 

In addition this would be a great contribution to the PROV community.

@Arthur, Eric, Jose
It would be great if you could shed some light in the actual differences 
between ShEx and Shapes (besides the syntax and the property group 
extensions by ShEx)

Best,
Dimitris

[1] 
https://github.com/pgroth/prov-constraints-validator-spin/blob/master/python/prov-constraints.py

 

Peter, would this be an acceptable direction for you?

Thanks,
Holger



On 8/3/14, 9:14 AM, Peter F. Patel-Schneider wrote:
I have indicated that I am satisfied with the current mention of possible 
solutions at the end of Section 3.

The work currently mentioned there is targeted towards RDF validation.  I 
am not in favour of including work that is not targeted towards RDF 
validation. If SPARQL fits into this category then I am not in favour of 
including SPARQL in this part of the charter at all.

I have never indicated that all possible solutions have to be included in 
the charter.  Suggesting this is just inflammatory.  I have never 
indicated that no possible solutions can be included in the charter. 
 Suggesting this is also inflammatory.

I am in favour of including multiple possible solutions, and in favour of 
including the ones that I think have sufficient gravitas.



Why do you think that SPARQL should be given the prominent place in the 
charter that it has in your suggested wording for deliverables?


peter





On 08/02/2014 03:37 PM, Irene Polikoff wrote:
Sort of. I believe you are interpreting "a blank sheet" in a very literal 
sense of the words which is clearly not what I meant. Other than that, I 
wanted to clarify if you are saying:

1) It is OK to state the possible solution in the charter as long as it is 
not mentioned in the deliverables section or
2) It is OK to state the possible solution in the charter as long as it is 
not SPARQL or
3) The charter should not mention any possible solutions anywhere or
4) The charter should equally mention all possible solutions that may 
exist in the world irrespective of their maturity and the number of such 
possible alternatives or
5) some combination of the above or something else altogether

Irene

-----Original Message-----
From: Peter F. Patel-Schneider [mailto:pfpschneider@gmail.com]
Sent: Saturday, August 02, 2014 6:11 PM
To: Irene Polikoff; 'Arthur Ryman'; public-rdf-shapes@w3.org
Subject: Re: Proposed change to the charter, section 4. Deliverables, 
Recommendation Track

You indeed have misunderstood my position.

I don't think that I have previously indicated that starting with a blank 
sheet is suboptimal, although I do agree that it is generally not a good 
idea.
   No charter draft that I have seen does start with a blank sheet, so 
this is somewhat of a moot point.

There are several implemented and deployed systems that claim to provide 
constraints for RDF.  Not all of them are given meaning in terms of 
SPARQL.
There is new work that claims to provide constraints for RDF. It is not 
based on SPARQL at all.  I have seen no work showing that SPARQL is 
adequate as an underpinning of all these systems.  Under these 
circumstances I feel that it is completely wrong to have SPARQL mentioned 
at all in the deliverables of the working group.

It this clear enough for you?

peter




On 08/02/2014 02:54 PM, Irene Polikoff wrote:
Peter,

I thought you agreed that starting with a blank sheet has proven to be 
suboptimal to ensuring success of a working group and its timely progress. 
And that while you were not against SPARQL per se, you were concerned with 
mandating its use in case the working group finds that it does not satisfy 
requirements.

Since my proposed wording addresses both of the issues, I must have 
misunderstood your position.

Irene

-----Original Message-----
From: Peter F. Patel-Schneider [mailto:pfpschneider@gmail.com]
Sent: Saturday, August 02, 2014 5:09 PM
To: Irene Polikoff; 'Arthur Ryman'; public-rdf-shapes@w3.org
Subject: Re: Proposed change to the charter, section 4. Deliverables,
Recommendation Track

Again, your proposed wording goes far beyond simply mentioning a possible 
solution.  Your proposed wording says that a particular approach is to be 
followed unless it is shown to be inadequate.

I do not support this proposed wording.  I do support wording like what is 
currently at the end of Section 3.

peter


On 08/02/2014 01:21 PM, Irene Polikoff wrote:
Because it identifies a possible solution and says that if it proves to be 
inadequate, the working group will choose another approach. Thus, the 
prime candidate is identified, but the group is not mandated to use it.

-----Original Message-----
From: Peter F. Patel-Schneider [mailto:pfpschneider@gmail.com]
Sent: Saturday, August 02, 2014 4:18 PM
To: Irene Polikoff; 'Arthur Ryman'; public-rdf-shapes@w3.org
Subject: Re: Proposed change to the charter, section 4. Deliverables,
Recommendation Track

Why would you think that this would be acceptable to me? This goes well 
beyond pointing at possible solutions or mentioning possible starting 
points.

peter

On 08/02/2014 01:13 PM, Irene Polikoff wrote:
Then, Arthur's strawman with the modification below should be acceptable:

The WG MUST produce:

1. A high-level RDF vocabulary that expresses commonly occurring 
constraints.
2. The semantics of the high-level constraints expressed in terms of 
SPARQL or, if SPARQL proves to be unsuitable for the use cases determined 
by the group, in an alternative language.
3. An RDF extension mechanism for expressing additional constraints, 
expressed in SPARQL.

The WG MAY produce:

1. A new compact, human readable syntax for expressing constraints with a 
corresponding semantics expressed in SPARQL or, if SPARQL proves to be 
unsuitable for the use cases determined by the group, in an alternative 
language.
2. A specification of how constraint validation interacts with inference.
3. A specification for graph normalization.
[1] http://www.w3.org/2014/data-shapes/charter

Irene

-----Original Message-----
From: Peter F. Patel-Schneider [mailto:pfpschneider@gmail.com]
Sent: Saturday, August 02, 2014 1:17 AM
To: Irene Polikoff; 'Arthur Ryman'; public-rdf-shapes@w3.org
Subject: Re: Proposed change to the charter, section 4.
Deliverables, Recommendation Track

I don't see much wrong in pointing at potential solutions, and even less 
mentioning possible starting points, but that's not what the proposed 
change to the charter is. Instead the proposed change mandates SPARQL as 
the semantics of constraints.  I think that this is in advance of any 
worked-out proposal for actually using SPARQL for this purpose.

If it turns out that SPARQL can be used to specify the semantics of 
constraints, then it may be reasonable to use SPARQL for this purpose.
However, mandating SPARQL's use even before its suitability has been 
demonstrated doesn't seem to me to be a good idea.

peter


On 08/01/2014 06:54 PM, Irene Polikoff wrote:
Not necessarily. As Jeremy Carroll said in one of the previous e-mails 
"W3C experience indicates that a WG with a blank sheet at the beginning 
often delivers the wrong stuff, late - and the broad ship that sails ends 
up as a narrow clique on arrival".

It is better to set a charter that identifies the prime candidate. As the 
work proceeds, the group may decide that the candidate doesn?t meet key 
requirements, but having initial stake in the ground is important to the 
effectiveness of the group, its ability to deliver on time and quality of 
its deliverables.

Irene

-----Original Message-----
From: Peter F. Patel-Schneider [mailto:pfpschneider@gmail.com]
Sent: Friday, August 01, 2014 5:53 PM
To: Arthur Ryman; public-rdf-shapes@w3.org
Subject: Re: Proposed change to the charter, section 4.
Deliverables, Recommendation Track

All these arguments may be fine, but isn't that up to the working group to 
decide?

peter


On 08/01/2014 02:42 PM, Arthur Ryman wrote:
Peter,

Thx for the response. I'm glad that we agree on making the
compact, human-friendly syntax optional.

Here is my rationale for advocating for the use of SPARQL.

1. We need to be precise about the meaning of constraints.
Therefore, we need to select some formalism for expressing the semantics.

2. The candidates for expressing semantics include:
2.1 Natural language
2.2 OWL ICV
2.3 SPARQL
2.4 Z
2.5 some other existing formal language
2.6 a new specification language that the wg invents

Pros and Cons

2.1 Natural language is imprecise and non-executable
2.2 OWL ICV is well-defined and executable, but not a W3C standard
and is not expressive enough as a general constraint language
2.3 SPARQL is a W3C standard, is very expressive, and is
executable
2.4 Z is very expressive but not well known and is non-executable
2.5 There are many other formal specification languages. Does
anyone want to advocate for one?
2.6 A new formalism - not the core focus of the workgroup.

3. Some one will need to build a reference implementation. A
SPARQL implementation will be easy to build if the semantics of
the constraints are in SPARQL.

4. We want the specification to be implemented and adopted. SPARQL
is a known quantity and many implementations exist.


Regards,
__________________________________________________________________
_
_
_
_
_____
Arthur Ryman, PhD

Chief Data Officer, Rational
Chief Architect, Portfolio & Strategy Management Distinguished
Engineer | Master Inventor | Academy of Technology

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:   "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
To:     Arthur Ryman/Toronto/IBM@IBMCA, public-rdf-shapes@w3.org,
Date:   08/01/2014 05:22 PM
Subject:        Re: Proposed change to the charter, section 4.
Deliverables, Recommendation   Track



I do agree that the emphasis in the charter on creating a
human-readable syntax is misplaced and that this deliverable
should be made optional. The proposal here, however, does very
much more than fixing this problem, and I view most of the other
changes in the proposal as undesirable.

Why should the group be required to specify semantics in terms of SPARQL?
There hasn't even been anything to show that SPARQL is adequate
for this purpose.  Why should the group be required to specify two
ways of expressing constraints, and one of them be SPARQL itself?
There hasn't been anything to show that this division is needed.
Why should a human-readable syntax for constraints be new?  There
hasn't been anything to show that existing syntaxes are unsuitable
for this purpose.  I don't think that it is appropriate to tie the
hands of the working group in any of these ways.

I do agree that the group should be required to define the meaning
of constraints.  This was a peculiar lack in the deliverables.

So my proposal would be to change the recommendation track
deliverables to

something like:

1. A syntax and semantics for shapes specifying how to construct
shape expressions and how shape expressions are evaluated against RDF 
graphs.

2. An RDF vocabulary for expressing these shapes in RDF triples,
so they can be stored, queried, analyzed, and manipulated with
normal RDF tools.

3. OPTIONAL A specification of how shape verification interacts
with inference.

4. OPTIONAL A compact, human-readable syntax for expressing shapes.

I would prefer the third deliverable to be required, but I'm not
going to complain if it is optional.

Although there are three syntaxes mentioned in these deliverables,
in keeping with the usual RDF situation there is nothing saying
that all of these three need to be different or even that they are
not all the same.  (Well, nothing beyond the implausibility of
using RDF triples as the basis of a compact, human-readable
syntax.)

peter


On 08/01/2014 12:44 PM, Arthur Ryman wrote:
The output of the wg is defined by its deliverables. Here is the
current text [1]

Recommendation Track:
1.      Compact, human readable syntax for expressing constraints on RDF
graph patterns (aka shapes), suitable for the use cases
determined by
the
group. This syntax might be a variation of an existing standard,
such as templates for SPARQL, or something new, such as ShExC.
2.      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.
The WG MAY produce a Recommendation for graph normalization.

This text is not acceptable to IBM because of the primary
emphasis it places on defining a possibly new compact, human readable 
syntax.
I believe this concern has been expressed repeatedly by many
people on the mailing list. Many people have indicated a strong
preference for
building
on existing standards. However, we have not seen any
corresponding modification of the charter. I'd therefore like to
propose a strawman change to this section of the charter and invite 
comment.
Here is the proposed new text:
The WG MUST produce:
1. A high-level RDF vocabulary that expresses commonly occurring
constraints.
2. The semantics of the high-level constraints expressed in terms
of SPARQL.
3. An RDF extension mechanism for expressing additional
constraints, expressed in SPARQL.
The WG MAY produce:
1. A new compact, human readable syntax for expressing
constraints with
a
corresponding semantics expressed in SPARQL.
2. A specification for graph normalization.
[1] http://www.w3.org/2014/data-shapes/charter

Regards,

__________________________________________________________________
_
_
_
_
_____
Arthur Ryman, PhD

Chief Data Officer, Rational
Chief Architect, Portfolio & Strategy Management Distinguished
Engineer | Master Inventor | Academy of Technology

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)



















-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Homepage:http://aksw.org/DimitrisKontokostas

Received on Wednesday, 6 August 2014 12:15:34 UTC