- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sat, 23 May 2020 17:40:56 +1000
- To: James Hudson <jameshudson3010@gmail.com>, Adam Kimball <adam@akimball.org>, "schema. org Mailing List" <public-schemaorg@w3.org>
- Message-ID: <9f135bc3-52e7-1c15-b008-53af6f0c618e@topquadrant.com>
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