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

Re: ISSUE-105: Possible compromise

From: Andy Seaborne <andy.seaborne@topquadrant.com>
Date: Thu, 8 Sep 2016 23:37:20 +0100
To: public-data-shapes-wg@w3.org
Message-ID: <3c7ee268-e4ed-43fa-1f98-6d2161ec6022@topquadrant.com>
SPARQL prologues compose - later ones reset from earlier ones (in fact, 
bizarre case, BASE can be multiple and even relative to an earlier BASE).

For Mark's example:

ex:MyShape
      a sh:Shape ;
      sh:sparql [
          sh:prefixes ex:MyPrefixes ;
          sh:prefixes ex:BasePrefixes ;
          sh:select "SELECT * { $this rdfs:seeAlso ex:MyResource }" ;
      ] .

there is a problem that the order of sh;prefixes statements matters and 
RDF does not, here, preserve order.

If we had sh:extends which causes a tree, so single parent, single path 
to the root, no order issues:

ex:MyPrefixes
      a sh:PrefixDeclaration ;
      sh:extends ex:BasePrefixes ;  # ******
      sh:sparqlPrologue
"
prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix owl:<http://www.w3.org/2002/07/owl#>
" .


would work to give:

"""
prefix rdfs: <http://w3c.nobody.can.remember.the.bloody.date>
prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix owl:<http://www.w3.org/2002/07/owl#>
"""


The rule is concatenate the chain from sh:prefixes to one that has no 
sh:extends.

     Andy

On 08/09/16 23:23, Holger Knublauch wrote:
> Yes this is, I believe, what was discussed as option b.
>
> BTW the sums of today's meetings were
>
> a) 2.4  (individually declared prefixes)
> b) 2.6  (prefixes as string blocks)
> c) 1.4  (no prefixes shorthand)
>
> One argument against b is that it becomes harder for tools to check for
> conflicts because the info is "just strings". I believe having a general
> triple-based syntax for prefixes would be beneficial elsewhere. Also
> note that the SPARQL prologue may contain a BASE declaration, opening up
> yet another level of complexity to the string concatenation.
>
> Holger
>
> [1] https://www.w3.org/TR/sparql11-query/#rBaseDecl
>
>
> On 9/09/2016 5:13, markh wrote:
>> Following today's conversations, Ted's suggestions about
>> concatenation and strings or graphs I thought to follow up
>>
>> If the 'prefixes' are defined in SPARQL syntax and the SPARQL query is
>> formed explicitly by string manipulation I think this may look
>> something like:
>>
>>
>> ex:BasePrefixes
>>       a sh:PrefixDeclaration ;
>>       sh:sparqlPrologue
>> "
>> prefix rdfs: <http://w3c.nobody.can.remember.the.bloody.date>
>> " .
>>
>> ex:MyPrefixes
>>       a sh:PrefixDeclaration ;
>>       sh:sparqlPrologue
>> "
>> prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
>> prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
>> prefix owl:<http://www.w3.org/2002/07/owl#>
>> " .
>>
>> ex:MyShape
>>       a sh:Shape ;
>>       sh:sparql [
>>           sh:prefixes ex:MyPrefixes ;
>>           sh:prefixes ex:BasePrefixes ;
>>           sh:select "SELECT * { $this rdfs:seeAlso ex:MyResource }" ;
>>       ] .
>>
>>
>> I wanted to write this down to see it and check my interpretation
>>
>> Is this consistent with people's views of what was discussed?
>>
>>
>> cheers
>> mark
>>
>>
>> On Fri, 2 Sep 2016 06:30:34 +1000
>> Holger Knublauch <holger@topquadrant.com> wrote:
>>
>>> Given that the majority of people in today's call were against having
>>> a simple sh:prefix property, I was asked to propose a variant that
>>> may be "just" acceptable to everyone. The idea of this proposal is
>>> that each node that defines a SPARQL query that wishes to reuse
>>> prefixes from elsewhere must explicitly point at those definitions.
>>> And the prefix declarations would live in a separate node that may
>>> extend the declarations from others.
>>>
>>> Example:
>>>
>>> ex:BasePrefixes
>>>       a sh:PrefixDeclaration ;
>>>       sh:declare [
>>>           sh:prefix "rdfs" ;
>>>           sh:namespace
>>> "http://w3c.nobody.can.remember.the.bloody.date" ; ] ;
>>>       sh:declare [
>>>           sh:prefix "sh" ;
>>>           ...
>>>       ] .
>>>
>>> ex:MyPrefixes
>>>       a sh:PrefixDeclaration ;
>>>       sh:extends ex:BasePrefixes ;
>>>       sh:declare [
>>>           sh:prefix "ex" ;
>>>           sh:namespace "http://example.com/ns#" ;
>>>       ] .
>>>
>>> ex:MyShape
>>>       a sh:Shape ;
>>>       sh:sparql [
>>>           sh:prefixes ex:MyPrefixes ;
>>>           sh:select "SELECT * { $this rdfs:seeAlso ex:MyResource }" ;
>>>       ] .
>>>
>>> The mechanism would be that the system would prepend the SELECT with
>>> the prefixes defined in any sh:prefixes, including those that
>>> sh:extends. An error would be flagged if prefixes conflict. Some
>>> tools can (and will) of course produce the sh:PrefixDeclarations
>>> automatically, and inject the sh:prefixes declarations if desired. I
>>> guess some tools will make this optional and may just inject the
>>> SPARQL prefix declarations automatically.
>>>
>>> A variation of this would be to have a standard set of prefixes that
>>> is always included by default, e.g. sh:DefaultPrefixes with rdf,
>>> rdfs, xsd, sh and owl prefixes. Clashes on those are extremely
>>> unlikely and many queries don't need any others, saving the
>>> sh:prefixes triple.
>>>
>>> Discussion: this is obviously a more verbose mechanism, with a lot of
>>> new properties. But it does IMHO address the main issues that were
>>> raised and people who are hand-writing Turtle files with lots of
>>> SPARQL queries at least have a shorthand notation.
>>>
>>> Regards,
>>> Holger
>>>
>>>
>>
>>
>
>
Received on Thursday, 8 September 2016 22:37:51 UTC

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