W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2015

Re: Requirement 2.11.7, Separation of Structural from Complex Constraints

From: Arthur Ryman <arthur.ryman@gmail.com>
Date: Tue, 17 Mar 2015 19:41:40 -0400
Message-ID: <CAApBiOkNphh52=J3A66HcndE85wp9a=1xBQRPK-mPqxX7hc6RQ@mail.gmail.com>
To: Jose Emilio Labra Gayo <jelabra@gmail.com>
Cc: Richard Cyganiak <richard@cyganiak.de>, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Jose,

I am sympathetic to your desire to have a way to write custom
constraints in a high-level expression language that is not directly
tied to SPARQL. However, this will add complexity to the simplest
profile of SHACL.

Couldn't we treat this new expression language on par with other
languages (e.g. SPARQL, Javascript, ...)? Couldn't we defer the
extension mechanism to the advanced profile of SHACL?

-- Arthur

On Thu, Mar 5, 2015 at 2:00 PM, Jose Emilio Labra Gayo
<jelabra@gmail.com> wrote:
> On Thu, Mar 5, 2015 at 5:22 PM, Richard Cyganiak <richard@cyganiak.de>
> wrote:
>>
>> Jose,
>>
>> There is a resolution that the language to be delivered by this group is
>> going to be called “SHACL”. There is another resolution that there may be
>> profiles of the language with limited functionality.
>
>
> Right.
>
>>
>> You seem to reject the notion of profiles,
>
>
> Not at all. There can be multiple profiles...as Karen has said in another
> email there could be even domain-specific profiles like some profiles for
> Schema.org.
>
>>
>> and instead want a “core language” called “SHACL” and a “non-core
>> language” called something else.
>
>
> No, I repeat again that I am proposing a well defined high-level or core
> language called SHACL. That language can have extensibility mechanism that
> enable to define complex constraints, and that language can have different
> profiles with different expressiveness for different purposes.
>
>> I don’t see this as compatible with previous resolutions.
>
>
> I don't see any incompatibility with previous resolutions.
>
> Best regards, Jose Labra
>>
>>
>> Best,
>> Richard
>>
>>
>>
>> > On 5 Mar 2015, at 15:17, Jose Emilio Labra Gayo <jelabra@gmail.com>
>> > wrote:
>> >
>> > Although I agree with the essence of the requirement, I don't agree with
>> > the new rephrasing which is based on one of the proposed alternatives (SHACL
>> > Minus SPARQL vs SHACL plus SPARQL) that is being discussed in another thread
>> > and that has not been resolved yet.
>> >
>> > I suggest a more neutral rephrasing like:
>> >
>> > [[[
>> > There shall be a core language or a SHACL profile that excludes any
>> > support for constraints defined via embedded SPARQL queries or other complex
>> > lower-level expressions. This is so that lightweight applications can
>> > validate constraints without requiring a SPARQL processor or similar
>> > subsystem.
>> > ]]]
>> >
>> > Best regards, Jose Labra
>> >
>> > On Thu, Mar 5, 2015 at 1:52 PM, Richard Cyganiak <richard@cyganiak.de>
>> > wrote:
>> > I took an action to propose a rephrasing of Requirement 2.11.7,
>> > “Separation of Structural from Complex Constraints”
>> >
>> > Link:
>> >
>> > https://www.w3.org/2014/data-shapes/wiki/Requirements#Separation_of_structural_from_complex_constraints
>> >
>> > I encourage in particular those who have voted on the original
>> > constraint (HK, KC:+1, SSt:+1, labra: +1, pfps: -1) to consider whether this
>> > changes their vote, and if so, update the wiki.
>> >
>> > The original requirement reads:
>> >
>> > [[[
>> > The language should separate structural constraints from more complex
>> > constraints (like arbitrary SPARQL or nested constraint expressions) so that
>> > certain light-weight applications can validate the constraints without a
>> > full SPARQL processor.
>> > ]]]
>> >
>> > My proposed rephrasing:
>> >
>> > [[[
>> > There shall be a SHACL profile that excludes any support for constraints
>> > defined via embedded SPARQL queries or other complex lower-level
>> > expressions. This is so that lightweight applications can validate
>> > constraints without requiring a SPARQL processor or similar subsystem.
>> > ]]]
>> >
>> > This completes ACTION-15.
>> >
>> > Richard
>> >
>> >
>> >
>> > --
>> > -- Jose Labra
>> >
>>
>
>
>
> --
> -- Jose Labra
>
Received on Tuesday, 17 March 2015 23:42:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:18 UTC