Re: Schema.org related SHACL shapes

On 22/05/2020 22:40, James Hudson wrote:
> Hello Holger,
>
> This discussion touches on another thread I started back in March
>
> Designing my vocabulary
> https://lists.w3.org/Archives/Public/public-schemaorg/2020Mar/0003.html
>
> Adam, I hope you don't mind being attached to this thread due to your 
> well thought-out opinions on /Designing my vocabulary/.
>
> I do not think there is any difference of opinion, but since Holger 
> expressed the idea that it could make sense to specify property 
> constraints in schemas for those properties where the semantics are 
> absolutely clear, like it would be for latitude or enumerations, I 
> wanted to make sure I understood this topic correctly.
>
> In the /Designing my vocabulary/ thread, I was considering a property 
> called chanceOfSuccess and thinking about how to declare the valid 
> range (minimum and maximum) for the property when used in a data 
> instance. A natural range would be 0% to 100%. However, based on 
> context, the actual valid range could be 30% - 80% when the property 
> is used in a data instance.
>
> In a discussion with Adam, I came to the conclusion that such 
> constraints should not be declared in the schema specification, but 
> belong outside of a schema specification in, for example, a 
> SHACL Shape. It does seem a strange to do this because it appears one 
> is specifying the schema twice. However, what convinced me that using 
> SHACL is the correct thing to do is properties like chanceOfSuccess 
> where the valid range is context dependent. It is impossible to 
> specify those constraints in a schema without doing something silly 
> like having a very large number of properties 
> like chanceOfSuccess10To50, chanceOfSuccess30To80, etc.
Shapes can narrow down each other's constraints. So if the global 
default shape has sh:minInclusive 0 and sh:maxInclusive 100 then you can 
add additional shapes in your own app to say sh:minInclusive 10 etc. As 
long as you only narrow down the set of valid value nodes, this is 
perfectly fine.
>
> p.s. Holger, if you could run your script again to update 
> http://datashapes.org/schema, I would find that useful. Curious...is 
> your script open source? Can it be shared?

The script is implemented as a bunch of SPIN rules (basically SPARQL 
INSERTs) in a file that comes with the download of TopBraid Composer 
(for which there is a free evaluation period). It's under 
TopBraid/Schema.org/schemaconverter.ui.ttlx there.

I have just updated the online version to today's snapshot.

Holger


>
> Regards,
> James
>
>
> On Fri, May 22, 2020 at 12:52 AM Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>
>     On 21/05/2020 22:10, James Hudson wrote:
>>     Hello Holger,
>>
>>     Thank you for the clarification.
>>
>>     This does prompt another question.
>>
>>     Consider, for example, the https://schema.org/latitude property.
>>
>>     When it is a Number, the value of a latitude, when expressed in
>>     degrees, should be between -90 to 90. Currently the SHACL Shape
>>     validating the latitude property would accept any valid instead
>>     of producing a validation error when the values is outside of the
>>     valid range. There are likely other (and better) similar examples
>>     which http://datashapes.org/schema will not produce expected
>>     validation errors for.
>>
>>     Given how the shape is created, this is understandable. It would
>>     require that valid ranges be specified and that is beyond the
>>     scope of what a schema is or should be. An exception to this
>>     might be properties like https://schema.org/byDay which, when it
>>     is a https://schema.org/DayOfWeek, may produce a validation error
>>     if an enumeration member is not provided.
>>
>>     While http://datashapes.org/schema provides a basis for a
>>     solution to validate schema.org <http://schema.org> data
>>     instances, it is missing information to produce validation errors
>>     when they would be expected.
>>
>>     Am I off base here?
>
>     You are correct. The SHACL schema from this (my) converter only
>     converts what it can infer from the original official document.
>     The official docs do not contain constraints such as the range of
>     latitude. I do not know if this is an intentional design decision,
>     but I guess adding something machine-readable (even if it uses
>     xsd:minInclusive instead of sh:minInclusive) in the RDFa would
>     make sense from my perspective. Of course, only in cases where the
>     semantics are absolutely clear.
>
>     Holger
>
>
>>
>>     Regards,
>>     James
>>
>>     On Wed, May 20, 2020 at 9:57 PM Holger Knublauch
>>     <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>>
>>
>>         On 21/05/2020 03:20, James Hudson wrote:
>>>         Hello,
>>>
>>>         Dan B.,
>>>
>>>             While I am disappointed that no one has already done my
>>>             work for me :-), what you have confirmed (I think) is
>>>             that it is work worth doing and there are no known red
>>>             flags against considering developing SHACL Shapes which
>>>             would validate schema.org <http://schema.org> data
>>>             instances.
>>>
>>>             If anyone can point me to specific work that have
>>>             experimented with creating SHACL Shapes which validate
>>>             schema.org <http://schema.org> data instances, I would
>>>             be interested. I will keep looking.
>>>
>>>             Based on the breadth and extent of schema.org
>>>             <http://schema.org>, it would seem to be a lot of work
>>>             for complete validation.
>>>
>>>
>>>         Alasdair,
>>>
>>>             I looked at your site, but did not see any SHACL Shapes
>>>             related to schema.org <http://schema.org> classes or
>>>             properties. I assume you are using them underneath
>>>             somewhere...? Can they be shared?
>>>
>>>
>>>         Gregory, Thomas,
>>>
>>>             Thank you for pointing me at
>>>             http://datashapes.org/schema. Unless I am mistaken, it (
>>>             http://datashapes.org/schema.ttl ) seems that is about
>>>             validating schema.org <http://schema.org> classes and
>>>             properties itself and not data instances.
>>>
>>         No, that SHACL file is actually for instances. It is
>>         generated from the original RDFa definition of the schema.org
>>         <http://schema.org> classes and properties and interprets the
>>         specified ranges as sh:datatype and sh:class constraints. So
>>         you *can* use it as a shapes graph when validating instances.
>>
>>         And yes, it's not entirely up to date - if anyone needs the
>>         very latest version I could re-run the generator (which is
>>         also bundled with TBC in case anyone has that).
>>
>>         Holger
>>
>>
>>>
>>>             Although, their "example file" (
>>>             http://datashapes.org/schemashacl.shapes.ttl ) is what I
>>>             am looking for, but it only covers one class. Still,
>>>             there will be things in there that I can use.
>>>
>>>             It does provide some nice examples for how to do certain
>>>             things in SHACL.
>>>
>>>
>>>         Umut, Elias,
>>>
>>>             Thank you for pointing me at semantify.it
>>>             <http://semantify.it>. I will have to take a closer
>>>             look, but it does not appear to have what I am looking
>>>             for this time, which is literally a SHACL Shape which
>>>             can validate https://schema.org/Invoice#Invoice-gen-367
>>>             , for example -- and beyond that, SHACL Shapes which
>>>             could validate data instances of all of the schema.org
>>>             <http://schema.org> classes and properties. Incomplete
>>>             solutions would be of value.
>>>
>>>
>>>         Regards,
>>>         James
>>>
>>>
>>>

Received on Saturday, 23 May 2020 07:41:16 UTC