W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > May 2016

Re: ISSUE-105: Prefixes in SPARQL fragments

From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Date: Fri, 6 May 2016 11:25:06 +0300
Message-ID: <CA+u4+a3anbcLD_Wh-Nc6mCCRyJG99q5ZLq7NNt4rrqpyh8dp_A@mail.gmail.com>
To: Miika Alonen <miika.alonen@csc.fi>
Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
Using Milka's link I noticed that IBM Shapes (OSLC) have a prefix
declaration mechanism
http://open-services.net/bin/view/Main/OslcCoreSpecification#Resource_Prefix_Definition

Jim, can you tell us what is the use for this since IBM Shapes does not use
SPARQL ?

On Fri, May 6, 2016 at 10:00 AM, Miika Alonen <miika.alonen@csc.fi> 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
>
> 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>
> 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://..." <http://...>
> ] ;
> >     sh:prefix [ sh:prefix "owl" ; sh:namespace "http://..." <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" < <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://..." <http://...>
> ] ;
> >     sh:prefix [ sh:prefix "owl" ; sh:namespace "http://..." <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" < <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://..." <http://...>
> ] ;
> >     sh:prefix [ sh:prefix "owl" ; sh:namespace "http://..." <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
> >>>
> >>>
> >
> >
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://
http://aligned-project.eu
Homepage:http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Friday, 6 May 2016 08:26:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:33 UTC