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

ISSUE-105: Possible compromise

From: Holger Knublauch <holger@topquadrant.com>
Date: Fri, 2 Sep 2016 06:30:34 +1000
To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Message-ID: <d166c5b0-d05d-a043-6210-957c89ec18ee@topquadrant.com>
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.


     a sh:PrefixDeclaration ;
     sh:declare [
         sh:prefix "rdfs" ;
         sh:namespace "http://w3c.nobody.can.remember.the.bloody.date" ;
     ] ;
     sh:declare [
         sh:prefix "sh" ;
     ] .

     a sh:PrefixDeclaration ;
     sh:extends ex:BasePrefixes ;
     sh:declare [
         sh:prefix "ex" ;
         sh:namespace "http://example.com/ns#" ;
     ] .

     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 

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.

Received on Thursday, 1 September 2016 20:31:03 UTC

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