You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Andy Seaborne <an...@apache.org> on 2020/07/19 09:53:17 UTC
SHACL-C [was: misleading parse exception message in Shacl.]
Hi Chris,
Oddly, sh:group/sh:order aren't in SHACLC - they look like they got
overlooked as they fit is quite naturally into the grammar. Maybe the WG
focus was validation and these aren't "validation".
dash:editor, and your own annotations:
There was a brief discussion on the SHACL CG list about allowing RDF in
SHACL-C. I didn't see a conclusion.
It can be done, in rather ungraceful way, with IMPORTS but you have ask
"why bother" if its splitting the shapes into compact and RDF parts.
Similarly, if there is an RDF block in a SHACL-C file: at least
everything is in one file but having to wire two sections of the file by
using the shape URIs is again, to me, kind of contrary to the compact,
ease of use, aspect of SHACL-C.
It looks like it would nearly work with inline Turtle inside the compact
shape with some parser contortions; property + the compact
class/datatype constraint would be ambiguous, but otherwise I think it
could be done because most things are using keywords. Another way would
be syntax to say "here be Turtle, same subject as the node/property a
this point".
All options that allow RDF are assuming the shape writer understands the
compact syntax as a specialised way to write some RDF and also what the
RDF structure looks like if they are going to add RDF into it. So it all
may be a step too far.
What I'd like in a SHACL-C file is being able to have RDFS
subclass/subproperty declarations.
Andy
On 17/07/2020 17:27, Chris Tomlinson wrote:
> Hi Andy,
>
> I haven’t looked into SHACLC. We do use features such as sh:group, sh:order, dash:editor and so on; as well as a few annotations of our own that are relevant to editing and some validation controls. Off-hand it isn’t clear how to use SHACLC and weave these other features in.
>
> The notation is nicely compact and if there’s an integration approach for additional features I’ll look deeper.
>
> Thanks,
> Chris
Re: SHACL-C
Posted by Andy Seaborne <an...@apache.org>.
On 21/07/2020 10:07, Holger Knublauch wrote:
>
> On 21/07/2020 18:29, Andy Seaborne wrote:
>> The grammar does not have words
>>
>> 'order', 'group', 'description', 'name', 'defaultValue'
>>
>> in the propertyParam or nodeParam rules
>>
>> So you can't concat the sh namespace with the token string.
>
> Thanks. I have mixed this up and thought I had generalized that rule.
> Should have checked :)
>
> Another missing term is sh:defaultValue. So how do people feel about
> adding that line to the grammar? Sounds like an easy fix.
>
> Further we could theoretically add sh:name and (less attractive)
> sh:description.
>
> And shall we add subClassOf?
The form
>> shapeClass ex:Company rdfs:subClassOf ex:Organization {
does not cover cases I am coming across.
My ideal is all description in one file. Modularising using IMPORT for
this is not nice. The domain is SHACLC shapes but also RDFS sub*of.
That means a general RDFS subClassOf declaration, not specific to
implicitClass shapes. They (implicitClass shapes) are a pattern in
SHACL, not fundamental to SHACL.
The class may not be a shape and it would apply for "class=" and throughout.
Having subClassOf and subPropertyOf in the same file as SHACLC makes for
as single place for a "schema".
CLASS ex:Company .
CLASS ex:Company subClassOf ex:Organization .
(the DOTS are unnecessary - like PREFIX).
The shapeClass-subClassOf might be useful as a short cut.
Andy
>
> Holger
>
>
>>
>>
>> propertyParam :
>>
>> 'deactivated' | 'severity' | 'message' |
>> 'class' | 'datatype' | 'nodeKind' |
>> 'minExclusive' | 'minInclusive' | 'maxExclusive' | 'maxInclusive' |
>> 'minLength' | 'maxLength' | 'pattern' | 'flags' | 'languageIn' |
>> 'uniqueLang' |
>> 'equals' | 'disjoint' | 'lessThan' | 'lessThanOrEquals' |
>> 'qualifiedValueShape' | 'qualifiedMinCount' | 'qualifiedMaxCount' |
>> 'qualifiedValueShapesDisjoint' |
>> 'closed' | 'ignoredProperties' | 'hasValue' | 'in' ;
>>
>> Andy
>>
>> On 20/07/2020 23:34, Holger Knublauch wrote:
>>> Hi Andy,
>>>
>>> not quite sure what you mean: is the spec unclear, or does it have an
>>> error? If yes, what would be better wording?
>>>
>>> Thanks,
>>> Holger
>>>
>>>
>>> On 20/07/2020 19:03, Andy Seaborne wrote:
>>>>
>>>>
>>>> On 19/07/2020 23:21, Holger Knublauch wrote:
>>>>> On 19/07/2020 19:53, Andy Seaborne wrote:
>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> Oddly, sh:group/sh:order aren't in SHACLC - they look like they
>>>>>> got overlooked as they fit is quite naturally into the grammar.
>>>>>> Maybe the WG focus was validation and these aren't "validation".
>>>>>
>>>>> All terms from the sh: namespace are supported at property shapes
>>>>> and node shapes, see
>>>>>
>>>>> https://w3c.github.io/shacl/shacl-compact-syntax/#rule-propertyValue
>>>>
>>>> "concatenating the sh namespace with the string value of
>>>> /propertyParam/"
>>>>
>>>> ("string value" taken to mean the string that is the token)
>>>>
>>>> Today, 2020-07-20, the words aren't in the propertyParam grammar rule.
>>>>
>>>> Andy
Re: SHACL-C
Posted by Holger Knublauch <ho...@topquadrant.com>.
On 21/07/2020 18:29, Andy Seaborne wrote:
> The grammar does not have words
>
> 'order', 'group', 'description', 'name', 'defaultValue'
>
> in the propertyParam or nodeParam rules
>
> So you can't concat the sh namespace with the token string.
Thanks. I have mixed this up and thought I had generalized that rule.
Should have checked :)
Another missing term is sh:defaultValue. So how do people feel about
adding that line to the grammar? Sounds like an easy fix.
Further we could theoretically add sh:name and (less attractive)
sh:description.
And shall we add subClassOf?
Holger
>
>
> propertyParam :
>
> 'deactivated' | 'severity' | 'message' |
> 'class' | 'datatype' | 'nodeKind' |
> 'minExclusive' | 'minInclusive' | 'maxExclusive' | 'maxInclusive' |
> 'minLength' | 'maxLength' | 'pattern' | 'flags' | 'languageIn' |
> 'uniqueLang' |
> 'equals' | 'disjoint' | 'lessThan' | 'lessThanOrEquals' |
> 'qualifiedValueShape' | 'qualifiedMinCount' | 'qualifiedMaxCount' |
> 'qualifiedValueShapesDisjoint' |
> 'closed' | 'ignoredProperties' | 'hasValue' | 'in' ;
>
> Andy
>
> On 20/07/2020 23:34, Holger Knublauch wrote:
>> Hi Andy,
>>
>> not quite sure what you mean: is the spec unclear, or does it have an
>> error? If yes, what would be better wording?
>>
>> Thanks,
>> Holger
>>
>>
>> On 20/07/2020 19:03, Andy Seaborne wrote:
>>>
>>>
>>> On 19/07/2020 23:21, Holger Knublauch wrote:
>>>> On 19/07/2020 19:53, Andy Seaborne wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> Oddly, sh:group/sh:order aren't in SHACLC - they look like they
>>>>> got overlooked as they fit is quite naturally into the grammar.
>>>>> Maybe the WG focus was validation and these aren't "validation".
>>>>
>>>> All terms from the sh: namespace are supported at property shapes
>>>> and node shapes, see
>>>>
>>>> https://w3c.github.io/shacl/shacl-compact-syntax/#rule-propertyValue
>>>
>>> "concatenating the sh namespace with the string value of
>>> /propertyParam/"
>>>
>>> ("string value" taken to mean the string that is the token)
>>>
>>> Today, 2020-07-20, the words aren't in the propertyParam grammar rule.
>>>
>>> Andy
Re: SHACL-C
Posted by Andy Seaborne <an...@apache.org>.
The grammar does not have words
'order', 'group', 'description', 'name', 'defaultValue'
in the propertyParam or nodeParam rules
So you can't concat the sh namespace with the token string.
propertyParam :
'deactivated' | 'severity' | 'message' |
'class' | 'datatype' | 'nodeKind' |
'minExclusive' | 'minInclusive' | 'maxExclusive' | 'maxInclusive' |
'minLength' | 'maxLength' | 'pattern' | 'flags' | 'languageIn' |
'uniqueLang' |
'equals' | 'disjoint' | 'lessThan' | 'lessThanOrEquals' |
'qualifiedValueShape' | 'qualifiedMinCount' | 'qualifiedMaxCount' |
'qualifiedValueShapesDisjoint' |
'closed' | 'ignoredProperties' | 'hasValue' | 'in' ;
Andy
On 20/07/2020 23:34, Holger Knublauch wrote:
> Hi Andy,
>
> not quite sure what you mean: is the spec unclear, or does it have an
> error? If yes, what would be better wording?
>
> Thanks,
> Holger
>
>
> On 20/07/2020 19:03, Andy Seaborne wrote:
>>
>>
>> On 19/07/2020 23:21, Holger Knublauch wrote:
>>> On 19/07/2020 19:53, Andy Seaborne wrote:
>>>
>>>> Hi Chris,
>>>>
>>>> Oddly, sh:group/sh:order aren't in SHACLC - they look like they got
>>>> overlooked as they fit is quite naturally into the grammar. Maybe
>>>> the WG focus was validation and these aren't "validation".
>>>
>>> All terms from the sh: namespace are supported at property shapes and
>>> node shapes, see
>>>
>>> https://w3c.github.io/shacl/shacl-compact-syntax/#rule-propertyValue
>>
>> "concatenating the sh namespace with the string value of /propertyParam/"
>>
>> ("string value" taken to mean the string that is the token)
>>
>> Today, 2020-07-20, the words aren't in the propertyParam grammar rule.
>>
>> Andy
Re: SHACL-C [was: misleading parse exception message in Shacl.]
Posted by Andy Seaborne <an...@apache.org>.
On 19/07/2020 23:21, Holger Knublauch wrote:
> On 19/07/2020 19:53, Andy Seaborne wrote:
>
>> Hi Chris,
>>
>> Oddly, sh:group/sh:order aren't in SHACLC - they look like they got
>> overlooked as they fit is quite naturally into the grammar. Maybe the
>> WG focus was validation and these aren't "validation".
>
> All terms from the sh: namespace are supported at property shapes and
> node shapes, see
>
> https://w3c.github.io/shacl/shacl-compact-syntax/#rule-propertyValue
"concatenating the sh namespace with the string value of /propertyParam/"
("string value" taken to mean the string that is the token)
Today, 2020-07-20, the words aren't in the propertyParam grammar rule.
Andy
Re: SHACL-C [was: misleading parse exception message in Shacl.]
Posted by Holger Knublauch <ho...@topquadrant.com>.
On 19/07/2020 19:53, Andy Seaborne wrote:
> Hi Chris,
>
> Oddly, sh:group/sh:order aren't in SHACLC - they look like they got
> overlooked as they fit is quite naturally into the grammar. Maybe the
> WG focus was validation and these aren't "validation".
All terms from the sh: namespace are supported at property shapes and
node shapes, see
https://w3c.github.io/shacl/shacl-compact-syntax/#rule-propertyValue
e.g.
ex:property xsd:string [0..1] order=0 .
should work. Theoretically this could be extended to allow other
prefixes such as dash: there too. This would then also cover
rdfs:subClassOf, e.g.
shapeClass ex:Company rdfs:subClassOf ex:Organization {
...
}
As the Compact Syntax is a living spec we could easily add this if there
is sufficient consensus.
The larger question of course becomes at what stage the syntax is no
longer compact. If we add more features, people could just as well use
TTL, which has the advantage of being more regular. I have no strong
opinion. (Likely better continued on the SHACL CG list)
Holger
>
> dash:editor, and your own annotations:
>
> There was a brief discussion on the SHACL CG list about allowing RDF
> in SHACL-C. I didn't see a conclusion.
>
> It can be done, in rather ungraceful way, with IMPORTS but you have
> ask "why bother" if its splitting the shapes into compact and RDF parts.
>
> Similarly, if there is an RDF block in a SHACL-C file: at least
> everything is in one file but having to wire two sections of the file
> by using the shape URIs is again, to me, kind of contrary to the
> compact, ease of use, aspect of SHACL-C.
>
> It looks like it would nearly work with inline Turtle inside the
> compact shape with some parser contortions; property + the compact
> class/datatype constraint would be ambiguous, but otherwise I think it
> could be done because most things are using keywords. Another way
> would be syntax to say "here be Turtle, same subject as the
> node/property a this point".
>
> All options that allow RDF are assuming the shape writer understands
> the compact syntax as a specialised way to write some RDF and also
> what the RDF structure looks like if they are going to add RDF into
> it. So it all may be a step too far.
>
> What I'd like in a SHACL-C file is being able to have RDFS
> subclass/subproperty declarations.
>
> Andy
>
> On 17/07/2020 17:27, Chris Tomlinson wrote:
>> Hi Andy,
>>
>> I haven’t looked into SHACLC. We do use features such as sh:group,
>> sh:order, dash:editor and so on; as well as a few annotations of our
>> own that are relevant to editing and some validation controls.
>> Off-hand it isn’t clear how to use SHACLC and weave these other
>> features in.
>>
>> The notation is nicely compact and if there’s an integration approach
>> for additional features I’ll look deeper.
>>
>> Thanks,
>> Chris