Re: ISSUE-105: Prefixes in SPARQL fragments

+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 

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" < 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# " ] . 
> 
> 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 " ) ; 
>> 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: 

BQ_BEGIN


On Apr 24, 2016 7:15 AM, "Holger Knublauch" < 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# " ] . 
> 
> 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 " ) ; 
>> 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 
>>> 
>>> 
> 
> 

BQ_END




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: 

BQ_BEGIN


On Apr 24, 2016 7:15 AM, "Holger Knublauch" < 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# " ] . 
> 
> 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 " ) ; 
>> 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 
>>> 
>>> 
> 
> 

BQ_END