Re: Schema.org related SHACL shapes

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.

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?

Regards,
James


On Fri, May 22, 2020 at 12:52 AM Holger Knublauch <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 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>
> 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 data instances.
>>
>> If anyone can point me to specific work that have experimented with
>> creating SHACL Shapes which validate schema.org data instances, I would
>> be interested. I will keep looking.
>>
>> Based on the breadth and extent of 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 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 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 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. 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 classes and properties. Incomplete solutions would be of
>> value.
>>
>>
>> Regards,
>> James
>>
>>
>>
>>