Re: Requirement 2.11.7, Separation of Structural from Complex Constraints

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

Received on Thursday, 5 March 2015 15:46:20 UTC