- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Thu, 5 Mar 2015 16:37:22 +0000
- To: kcoyle@kcoyle.net
- Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
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. 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 >
Received on Thursday, 5 March 2015 16:37:48 UTC