- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 9 Sep 2016 08:23:58 +1000
- To: public-data-shapes-wg@w3.org
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:24:30 UTC