- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sat, 7 May 2016 15:13:54 +1000
- To: public-data-shapes-wg@w3.org
On 7/05/2016 4:03, Karen Coyle wrote: > > > On 5/6/16 12:00 AM, Miika Alonen wrote: >> +1 for defining sh:prefix and sh:namespace >> >> Its about time to standardize this: >> http://lov.okfn.org/dataset/lov/terms?q=prefix >> >> (wow, never even heard about https://www.w3.org/ns/rdfa#prefix) >> >> Its also one of the suggested requirements from RDF Application >> profiles: >> http://wiki.dublincore.org/index.php/RDF_Application_Profiles/Requirements#R-220_Define_used_vocabulary >> > > However, I don't recall any discussion of "fragments" in the DCMI > group, similar to the SPARQL fragments anticipated here. That may > simply be because the DCMI group's discussion did not go to the next > step of detail. The prefix requirement linked here implies prefix > designation for an application profile document as a whole, thus > similar to methods used in various serializations. > > Assuming that there is a need to designate prefixes for fragments of > documents of various kinds, I am reluctant to see a SHACL-specific > solution. As Miika pointed out, there is a whole catalog of other namespaces that try to solve very similar issues. None of them is in a W3C standard. Putting something like sh:prefix into an official W3C standard may be just the tipping point to stop the proliferation of local solutions. So, it could go into the SHACL namespace without being limited to SHACL. SHACL would be one consumer among others. > At the same time, I understand the immediate need. I think we need, > however, to clarify what we expect in the pre-SHACL process on both > shapes and data graphs. Already there is the decision that rdf:type > statements must be explicit in both graphs, even though that implies > some pre-processing. Usually no pre-processing of the data graph is needed. The language is designed so that it walks the subclass hierarchy in a couple of important places, making the (expensive and often even impractical) pre-processing of rdf:type triples unnecessary. > A shapes graph that makes use of SPARQL or SHACL fragments needs to > inject context-specific prefixes, and this is done as a pre-processing > step, can this be solved by an expansion of the prefixed IRIs? That > would obviate any need for a new solution. The idea of a sh:prefix property is that people can share their SPARQL queries without having to repeat the same prefixes over and over again. The engine will then automatically insert the missing prefixes into the SPARQL queries. This does not require changes to the shapes graphs, but is just something that happens before the sh:sparql triples are converted into executable SPARQL queries. HTH Holger > > kc > >> >> The use case for the application profiles is also that there is standard >> way to add descriptions about the used vocabularies. Not all of the used >> vocabularies are resolvable and some are still "hidden" in chargeable >> (ISO/CEN, etc) standards. >> >> I think that the whole point of this is to minimize confusion and make >> it possible to declare preferred prefixes, used namespaces and document >> the intended use of the vocabularies. >> >> Best Regards, >> Miika Alonen >> >> CSC - IT Center for Science >> miika.alonen@csc.fi >> >> ------------------------------------------------------------------------ >> *From: *"Holger Knublauch" <holger@topquadrant.com> >> *To: *"public-data-shapes-wg" <public-data-shapes-wg@w3.org> >> *Sent: *Thursday, 5 May, 2016 06:15:14 >> *Subject: *Re: ISSUE-105: Prefixes in SPARQL fragments >> >> Just to give further input of why SHACL should include something like >> sh:prefix. >> >> I collected some statistics about stored SPARQL queries in our product. >> These queries are not only constraints, but most of them are part of >> user interface code (SPARQL Web Pages). We have 899 SELECT queries, 240 >> MODIFY, 173 ASK and 43 CONSTRUCT queries. We have 741 SPIN functions, >> 101 magic properties. And we have thousands (!) of small SPARQL snippets >> (stand-alone FILTER/BIND expressions) in IF/LET statements that drive >> the UI. It would be nice to migrate to SHACL syntax in the future, but >> having to repeat all used prefix declarations thousands of times will >> lead to excessive bloat. Note that these statistics only include the >> standard UI modules in our product - we have many more cases (such as >> SPIN rules and SPARQLMotion scripts) in custom consulting projects and >> customer deployments. >> >> I acknowledge that all points raised by others here (such as difficulty >> of copy and paste, potential confusion with duplicate prefixes and the >> extra overhead of managing sh:prefix triples) are valid. But these >> points do need to be weighed against the cost that also will be there if >> we don't provide anything. >> >> My strong preference remains to support simple ?namespace sh:prefix >> ?prefix triples. This is a predicate that would have been useful to >> standardize a long time ago, for use cases that go beyond SHACL. For >> example it is a perfectly valid scenario that people upload and edit >> resources to a database (that may not manage prefixes) yet want to track >> how these will look like when serialized back to files. It is also a >> common requirement to query the prefix in SPARQL, e.g. to build display >> strings or abbreviations. >> >> In SPIN we did not have this issue because SPIN uses an RDF data model >> to represent queries. This avoids the prefix question because proper >> references to URIs are used, but has the drawbacks that it leads to >> almost unmaintainable Turtle files and that the verbatim syntax as >> entered by the user is lost (e.g. indentation, line breaks formatting >> and # comments). For people who are using SPARQL heavily (such as in >> TQ's products), these aspects are very important. >> >> Holger >> >> >> >> On 24/04/2016 17:41, Eric Prud'hommeaux wrote: >> >> On Apr 24, 2016 7:15 AM, "Holger Knublauch" >> <<mailto:holger@topquadrant.com>holger@topquadrant.com> wrote: >> > >> > That's an interesting thought, Peter. We could extend and >> generalize this further, basically eliminating the problem of >> possible prefix conflicts: Each sh:sparql triple is already wrapped >> into an object (such as sh:SPARQLValuesDeriver, >> sh:SPARQLSelectValidator, subclasses of sh:SPARQLExecutable) in the >> current draft. These wrapper objects could all have another property >> sh:prefixes, making it explicit which prefixes are to be used: >> > >> > sh:DefaultPrefixes >> > a sh:PrefixDeclaration ; >> > sh:prefix [ sh:prefix "rdf" ; sh:namespace "http://..." ] ; >> > sh:prefix [ sh:prefix "owl" ; sh:namespace "http://..." ] ; >> > ... >> > >> > ex:MyPrefixes >> > a sh:PrefixDeclaration ; >> > sh:extends sh:DefaultPrefixes ; >> > sh:prefix [ sh:prefix "ex" ; sh:namespace >> "<http://example.com/ns#>http://example.com/ns#" ] . >> > >> > and then >> > >> > >> > ex:MyShape >> > a sh:Shape ; >> > sh:property [ >> > sh:predicate ex:grandParent ; >> > sh:derivedValues [ >> > a sh:SPARQLValuesDeriver ; >> > sh:prefixes ex:MyPrefixes ; >> > >> > sh:sparql "$this ex:parent/ex:parent ?value" ; >> > ] >> > ] . >> > >> > Very chatty syntax, but hopefully closer to acceptable to those >> who are currently against the whole idea. >> >> This doesn't address Mark's comment about cut/pastability but very >> nicely reduces the uncertainty associated with default prefixes. >> >> > Holger >> > >> > >> > On 23/04/2016 22:52, Peter F. Patel-Schneider wrote: >> >> >> >> Another possible approach would be to have a property on these >> constructs that >> >> provided prefixes for the construct only, as in >> >> >> >> ex:MyShape >> >> a sh:Shape ; >> >> sh:property [ >> >> sh:predicate ex:grandParent ; >> >> sh:derivedValues [ >> >> a sh:SPARQLValuesDeriver ; >> >> sh:prefixHere ( "ex" >> "<http://example.com>http://example.com" ) ; >> >> sh:sparql "$this ex:parent/ex:parent ?value" ; >> >> ] >> >> ] . >> >> >> >> On 04/22/2016 04:35 PM, Holger Knublauch wrote: >> >>> >> >>> I just thought about another problem with prefixes. Currently >> we have one >> >>> construct in the spec that operates on SPARQL fragments: >> >>> >> >>> ex:MyShape >> >>> a sh:Shape ; >> >>> sh:property [ >> >>> sh:predicate ex:grandParent ; >> >>> sh:derivedValues [ >> >>> a sh:SPARQLValuesDeriver ; >> >>> sh:sparql "$this ex:parent/ex:parent ?value" ; >> >>> ] >> >>> ] . >> >>> >> >>> Without something like sh:prefix, people would need to always >> spell out the >> >>> full URIs, because they cannot create PREFIX declarations in a >> SPARQL >> >>> fragment. We already do have other use cases of such fragments >> in our tool >> >>> suite (for expressions that constraint the applicability of >> menu items etc), >> >>> and it is quite plausible that the WG may want to adopt the >> following syntax >> >>> for path-based constraints in the future: >> >>> >> >>> ex:MyShape >> >>> a sh:Shape ; >> >>> sh:constraint [ >> >>> a sh:PathConstraint ; >> >>> sh:path "ex:parent/ex:parent" ; >> >>> sh:minCount 2 ; >> >>> sh:maxCount 4 ; >> >>> ] . >> >>> >> >>> Without sh:prefix we would essentially rule out these syntactic >> choices, >> >>> unless we can get users enthusiastic about always using full >> URIs. >> >>> >> >>> As always, there are work-arounds, e.g. we could force >> everything to be SELECT >> >>> or ASK queries. But at some stage I find the pain points are >> really becoming >> >>> too big. >> >>> >> >>> Thanks, >> >>> Holger >> >>> >> >>> >> > >> > >> >> >> >> >> Best Regards, >> Miika Alonen >> >> CSC - IT Center for Science >> miika.alonen@csc.fi >> >> ------------------------------------------------------------------------ >> *From: *"Holger Knublauch" <holger@topquadrant.com> >> *To: *"public-data-shapes-wg" <public-data-shapes-wg@w3.org> >> *Sent: *Thursday, 5 May, 2016 06:15:14 >> *Subject: *Re: ISSUE-105: Prefixes in SPARQL fragments >> >> Just to give further input of why SHACL should include something like >> sh:prefix. >> >> I collected some statistics about stored SPARQL queries in our product. >> These queries are not only constraints, but most of them are part of >> user interface code (SPARQL Web Pages). We have 899 SELECT queries, 240 >> MODIFY, 173 ASK and 43 CONSTRUCT queries. We have 741 SPIN functions, >> 101 magic properties. And we have thousands (!) of small SPARQL snippets >> (stand-alone FILTER/BIND expressions) in IF/LET statements that drive >> the UI. It would be nice to migrate to SHACL syntax in the future, but >> having to repeat all used prefix declarations thousands of times will >> lead to excessive bloat. Note that these statistics only include the >> standard UI modules in our product - we have many more cases (such as >> SPIN rules and SPARQLMotion scripts) in custom consulting projects and >> customer deployments. >> >> I acknowledge that all points raised by others here (such as difficulty >> of copy and paste, potential confusion with duplicate prefixes and the >> extra overhead of managing sh:prefix triples) are valid. But these >> points do need to be weighed against the cost that also will be there if >> we don't provide anything. >> >> My strong preference remains to support simple ?namespace sh:prefix >> ?prefix triples. This is a predicate that would have been useful to >> standardize a long time ago, for use cases that go beyond SHACL. For >> example it is a perfectly valid scenario that people upload and edit >> resources to a database (that may not manage prefixes) yet want to track >> how these will look like when serialized back to files. It is also a >> common requirement to query the prefix in SPARQL, e.g. to build display >> strings or abbreviations. >> >> In SPIN we did not have this issue because SPIN uses an RDF data model >> to represent queries. This avoids the prefix question because proper >> references to URIs are used, but has the drawbacks that it leads to >> almost unmaintainable Turtle files and that the verbatim syntax as >> entered by the user is lost (e.g. indentation, line breaks formatting >> and # comments). For people who are using SPARQL heavily (such as in >> TQ's products), these aspects are very important. >> >> Holger >> >> >> >> On 24/04/2016 17:41, Eric Prud'hommeaux wrote: >> >> On Apr 24, 2016 7:15 AM, "Holger Knublauch" >> <<mailto:holger@topquadrant.com>holger@topquadrant.com> wrote: >> > >> > That's an interesting thought, Peter. We could extend and >> generalize this further, basically eliminating the problem of >> possible prefix conflicts: Each sh:sparql triple is already wrapped >> into an object (such as sh:SPARQLValuesDeriver, >> sh:SPARQLSelectValidator, subclasses of sh:SPARQLExecutable) in the >> current draft. These wrapper objects could all have another property >> sh:prefixes, making it explicit which prefixes are to be used: >> > >> > sh:DefaultPrefixes >> > a sh:PrefixDeclaration ; >> > sh:prefix [ sh:prefix "rdf" ; sh:namespace "http://..." ] ; >> > sh:prefix [ sh:prefix "owl" ; sh:namespace "http://..." ] ; >> > ... >> > >> > ex:MyPrefixes >> > a sh:PrefixDeclaration ; >> > sh:extends sh:DefaultPrefixes ; >> > sh:prefix [ sh:prefix "ex" ; sh:namespace >> "<http://example.com/ns#>http://example.com/ns#" ] . >> > >> > and then >> > >> > >> > ex:MyShape >> > a sh:Shape ; >> > sh:property [ >> > sh:predicate ex:grandParent ; >> > sh:derivedValues [ >> > a sh:SPARQLValuesDeriver ; >> > sh:prefixes ex:MyPrefixes ; >> > >> > sh:sparql "$this ex:parent/ex:parent ?value" ; >> > ] >> > ] . >> > >> > Very chatty syntax, but hopefully closer to acceptable to those >> who are currently against the whole idea. >> >> This doesn't address Mark's comment about cut/pastability but very >> nicely reduces the uncertainty associated with default prefixes. >> >> > Holger >> > >> > >> > On 23/04/2016 22:52, Peter F. Patel-Schneider wrote: >> >> >> >> Another possible approach would be to have a property on these >> constructs that >> >> provided prefixes for the construct only, as in >> >> >> >> ex:MyShape >> >> a sh:Shape ; >> >> sh:property [ >> >> sh:predicate ex:grandParent ; >> >> sh:derivedValues [ >> >> a sh:SPARQLValuesDeriver ; >> >> sh:prefixHere ( "ex" >> "<http://example.com>http://example.com" ) ; >> >> sh:sparql "$this ex:parent/ex:parent ?value" ; >> >> ] >> >> ] . >> >> >> >> On 04/22/2016 04:35 PM, Holger Knublauch wrote: >> >>> >> >>> I just thought about another problem with prefixes. Currently >> we have one >> >>> construct in the spec that operates on SPARQL fragments: >> >>> >> >>> ex:MyShape >> >>> a sh:Shape ; >> >>> sh:property [ >> >>> sh:predicate ex:grandParent ; >> >>> sh:derivedValues [ >> >>> a sh:SPARQLValuesDeriver ; >> >>> sh:sparql "$this ex:parent/ex:parent ?value" ; >> >>> ] >> >>> ] . >> >>> >> >>> Without something like sh:prefix, people would need to always >> spell out the >> >>> full URIs, because they cannot create PREFIX declarations in a >> SPARQL >> >>> fragment. We already do have other use cases of such fragments >> in our tool >> >>> suite (for expressions that constraint the applicability of >> menu items etc), >> >>> and it is quite plausible that the WG may want to adopt the >> following syntax >> >>> for path-based constraints in the future: >> >>> >> >>> ex:MyShape >> >>> a sh:Shape ; >> >>> sh:constraint [ >> >>> a sh:PathConstraint ; >> >>> sh:path "ex:parent/ex:parent" ; >> >>> sh:minCount 2 ; >> >>> sh:maxCount 4 ; >> >>> ] . >> >>> >> >>> Without sh:prefix we would essentially rule out these syntactic >> choices, >> >>> unless we can get users enthusiastic about always using full >> URIs. >> >>> >> >>> As always, there are work-arounds, e.g. we could force >> everything to be SELECT >> >>> or ASK queries. But at some stage I find the pain points are >> really becoming >> >>> too big. >> >>> >> >>> Thanks, >> >>> Holger >> >>> >> >>> >> > >> > >> >> >> >> >> Best Regards, >> Miika Alonen >> >> CSC - IT Center for Science >> miika.alonen@csc.fi >> >> ------------------------------------------------------------------------ >> *From: *"Holger Knublauch" <holger@topquadrant.com> >> *To: *"public-data-shapes-wg" <public-data-shapes-wg@w3.org> >> *Sent: *Thursday, 5 May, 2016 06:15:14 >> *Subject: *Re: ISSUE-105: Prefixes in SPARQL fragments >> >> Just to give further input of why SHACL should include something like >> sh:prefix. >> >> I collected some statistics about stored SPARQL queries in our product. >> These queries are not only constraints, but most of them are part of >> user interface code (SPARQL Web Pages). We have 899 SELECT queries, 240 >> MODIFY, 173 ASK and 43 CONSTRUCT queries. We have 741 SPIN functions, >> 101 magic properties. And we have thousands (!) of small SPARQL snippets >> (stand-alone FILTER/BIND expressions) in IF/LET statements that drive >> the UI. It would be nice to migrate to SHACL syntax in the future, but >> having to repeat all used prefix declarations thousands of times will >> lead to excessive bloat. Note that these statistics only include the >> standard UI modules in our product - we have many more cases (such as >> SPIN rules and SPARQLMotion scripts) in custom consulting projects and >> customer deployments. >> >> I acknowledge that all points raised by others here (such as difficulty >> of copy and paste, potential confusion with duplicate prefixes and the >> extra overhead of managing sh:prefix triples) are valid. But these >> points do need to be weighed against the cost that also will be there if >> we don't provide anything. >> >> My strong preference remains to support simple ?namespace sh:prefix >> ?prefix triples. This is a predicate that would have been useful to >> standardize a long time ago, for use cases that go beyond SHACL. For >> example it is a perfectly valid scenario that people upload and edit >> resources to a database (that may not manage prefixes) yet want to track >> how these will look like when serialized back to files. It is also a >> common requirement to query the prefix in SPARQL, e.g. to build display >> strings or abbreviations. >> >> In SPIN we did not have this issue because SPIN uses an RDF data model >> to represent queries. This avoids the prefix question because proper >> references to URIs are used, but has the drawbacks that it leads to >> almost unmaintainable Turtle files and that the verbatim syntax as >> entered by the user is lost (e.g. indentation, line breaks formatting >> and # comments). For people who are using SPARQL heavily (such as in >> TQ's products), these aspects are very important. >> >> Holger >> >> >> >> On 24/04/2016 17:41, Eric Prud'hommeaux wrote: >> >> On Apr 24, 2016 7:15 AM, "Holger Knublauch" >> <<mailto:holger@topquadrant.com>holger@topquadrant.com> wrote: >> > >> > That's an interesting thought, Peter. We could extend and >> generalize this further, basically eliminating the problem of >> possible prefix conflicts: Each sh:sparql triple is already wrapped >> into an object (such as sh:SPARQLValuesDeriver, >> sh:SPARQLSelectValidator, subclasses of sh:SPARQLExecutable) in the >> current draft. These wrapper objects could all have another property >> sh:prefixes, making it explicit which prefixes are to be used: >> > >> > sh:DefaultPrefixes >> > a sh:PrefixDeclaration ; >> > sh:prefix [ sh:prefix "rdf" ; sh:namespace "http://..." ] ; >> > sh:prefix [ sh:prefix "owl" ; sh:namespace "http://..." ] ; >> > ... >> > >> > ex:MyPrefixes >> > a sh:PrefixDeclaration ; >> > sh:extends sh:DefaultPrefixes ; >> > sh:prefix [ sh:prefix "ex" ; sh:namespace >> "<http://example.com/ns#>http://example.com/ns#" ] . >> > >> > and then >> > >> > >> > ex:MyShape >> > a sh:Shape ; >> > sh:property [ >> > sh:predicate ex:grandParent ; >> > sh:derivedValues [ >> > a sh:SPARQLValuesDeriver ; >> > sh:prefixes ex:MyPrefixes ; >> > >> > sh:sparql "$this ex:parent/ex:parent ?value" ; >> > ] >> > ] . >> > >> > Very chatty syntax, but hopefully closer to acceptable to those >> who are currently against the whole idea. >> >> This doesn't address Mark's comment about cut/pastability but very >> nicely reduces the uncertainty associated with default prefixes. >> >> > Holger >> > >> > >> > On 23/04/2016 22:52, Peter F. Patel-Schneider wrote: >> >> >> >> Another possible approach would be to have a property on these >> constructs that >> >> provided prefixes for the construct only, as in >> >> >> >> ex:MyShape >> >> a sh:Shape ; >> >> sh:property [ >> >> sh:predicate ex:grandParent ; >> >> sh:derivedValues [ >> >> a sh:SPARQLValuesDeriver ; >> >> sh:prefixHere ( "ex" >> "<http://example.com>http://example.com" ) ; >> >> sh:sparql "$this ex:parent/ex:parent ?value" ; >> >> ] >> >> ] . >> >> >> >> On 04/22/2016 04:35 PM, Holger Knublauch wrote: >> >>> >> >>> I just thought about another problem with prefixes. Currently >> we have one >> >>> construct in the spec that operates on SPARQL fragments: >> >>> >> >>> ex:MyShape >> >>> a sh:Shape ; >> >>> sh:property [ >> >>> sh:predicate ex:grandParent ; >> >>> sh:derivedValues [ >> >>> a sh:SPARQLValuesDeriver ; >> >>> sh:sparql "$this ex:parent/ex:parent ?value" ; >> >>> ] >> >>> ] . >> >>> >> >>> Without something like sh:prefix, people would need to always >> spell out the >> >>> full URIs, because they cannot create PREFIX declarations in a >> SPARQL >> >>> fragment. We already do have other use cases of such fragments >> in our tool >> >>> suite (for expressions that constraint the applicability of >> menu items etc), >> >>> and it is quite plausible that the WG may want to adopt the >> following syntax >> >>> for path-based constraints in the future: >> >>> >> >>> ex:MyShape >> >>> a sh:Shape ; >> >>> sh:constraint [ >> >>> a sh:PathConstraint ; >> >>> sh:path "ex:parent/ex:parent" ; >> >>> sh:minCount 2 ; >> >>> sh:maxCount 4 ; >> >>> ] . >> >>> >> >>> Without sh:prefix we would essentially rule out these syntactic >> choices, >> >>> unless we can get users enthusiastic about always using full >> URIs. >> >>> >> >>> As always, there are work-arounds, e.g. we could force >> everything to be SELECT >> >>> or ASK queries. But at some stage I find the pain points are >> really becoming >> >>> too big. >> >>> >> >>> Thanks, >> >>> Holger >> >>> >> >>> >> > >> > >> >> >
Received on Saturday, 7 May 2016 05:38:47 UTC