Re: Requirement 2.11.7, Separation of Structural from Complex Constraints

On Thu, Mar 5, 2015 at 5:37 PM, Richard Cyganiak <richard@cyganiak.de>
wrote:

> Hi Karen,
>
> I was wondering about the wording in the original requirement that
> referred to disallowing “nested constraints” and couldn’t quite make sense
> of it. Your message explains it.
>
> I believe the requirement that you have in mind and the one that Jose (and
> me) have in mind are different.
>
> I think that Jose’s point is that using SPARQL should be *impossible* in
> the high-level language.
>

No, I think I had already clarified my point in other threads.

I have no problem if someone wants to implement the high-level language
using SPARQL...what I oppose is that the high-level language should only be
implementable in SPARQL.  What I am proposing is that the WG defines what
is the high-level language in a precise way so that different vendors can
implement it as they want.

I think your point is that using SPARQL should be *unnecessary* in the
> high-level language as long as one only wants to express those constraints
> supported in DSP.
>
> Best,
> Richard
>
>
> > On 5 Mar 2015, at 15:45, Karen Coyle <kcoyle@kcoyle.net> wrote:
> >
> > I'll admit that I had my own definition of "structural constraints" in
> mind, although not necessarily well-defined as such, when I voted on this.
> The difference between "arbitrary SPARQL" and "embedded SPARQL" isn't clear
> to me, nor what is or isn't structural about them.
> >
> > The structural constraints that I have in mind are those of the Dublin
> Core Description Set Profile [1]. The DSP essentially defines a unit of
> metadata analogous to what we think of as  "record." It nests things
> (entities) and their descriptions (properties). It can't, however, be
> entirely separated from some key constraints, most notably cardinality. The
> DSP also includes constraints on values (by type and by content), but those
> are not structural in my mind. It does not define any comparisons or
> dependencies (if A then B or C).
> >
> > The DSP imitates simple pre-Semantic Web metadata. It defines entities
> and attributes, and combines them into a single metadata "description."
> This is a common, albeit not semantically powerful, approach to metadata,
> and one that I think will continue to be used for things like catalogs and
> inventories. I'm pretty sure, though, that it can be implemented in SPARQL.
> For that reason, I do see this as a contrast to SPARQL, but a difference in
> complexity in general, possibly the same as what others have called a
> "core," or a "higher level language."
> >
> > So...
> >
> > "The language should permit a basic definition of described things and
> their properties using the simplest possible language."
> >
> > (No, I'm not totally satisfied with that myself, but it's the best I can
> do at the moment.)
> >
> > kc
> > [1] http://dublincore.org/documents/dc-dsp/
> >
> > On 3/5/15 4:52 AM, Richard Cyganiak 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
> >>
> >
> > --
> > Karen Coyle
> > kcoyle@kcoyle.net http://kcoyle.net
> > m: 1-510-435-8234
> > skype: kcoylenet/+1-510-984-3600
> >
>
>
>


-- 
-- Jose Labra