W3C home > Mailing lists > Public > public-schemaorg@w3.org > March 2020

Re: Designing my vocabulary

From: Martynas Jusevičius <martynas@atomgraph.com>
Date: Fri, 13 Mar 2020 14:59:31 +0100
Message-ID: <CAE35Vmxqwa2EAMWiqgxcLnG3eYAd=1aRFkbQSZtiRrYy=5cfmw@mail.gmail.com>
To: James Hudson <jameshudson3010@gmail.com>
Cc: "schema. org Mailing List" <public-schemaorg@w3.org>

the common case is instances having a property with a value and the
"schema" defining a constraint (using SHACL, SPIN etc.) for that
property with the range of valid values. How would you enforce the
constraint if there was no such distinction and the constraints were
part of instance data?

I don't think your SHACL example uses the actual range constraints.
"4.3 Value Range Constraint Components" looks like what you need:

I'd also suggest to use Turtle for your examples, to get away from the
overhead of the JSON-LD syntax and get closer to triples.

On Fri, Mar 13, 2020 at 2:47 PM James Hudson <jameshudson3010@gmail.com> wrote:
> Hello,
> Since I hate mailing lists threads which just end without any resolution or summary, I wanted to add what I learned, primarily in conversation with Adam K, in case others are interested now or later.
> Based on my research into this topic there appears to be two reasonable solutions. Perhaps one solution is more reasonable then the other.
> One key is to recognize that constraints exist as a concept outside of the instance of a class and should be outside of the actual instance data.
> The first solution is to adopt https://www.w3.org/TR/shacl/. It is a W3C recommendation and supported project. It provides a well defined, generic, and powerful system for applying constraints to properties. There are standard libraries which implement SHACL which provide enforcement for free. The caveat here is that adopting SHACL may provide more power and flexibility than is needed by a project and the overhead of maintaining Shape files may not be worthwhile. Whether this is an issue will only be known with time and experience as the technology is new.
> The second solution follows this general model:
>     {
>       "@id": "http://my-company.org/chanceOfSuccess",
>       "@type": "rdf:Property",
>       "http://schema.org/domainIncludes": {
>         "@id": "http://my-company.org/Event"
>       },
>       "http://schema.org/rangeIncludes": {
>           "@id": "http://schema.org/QuantitativeValue"
>       },
>       “ex:chanceMinValue” : “30”,
>       “ex:chanceMaxValue” : “60”,
>       "rdfs:comment": “Allow values are only 30-60.",
>       "rdfs:label": “chanceOfSuccess with range 30-60"
>     }
> In this case, we declare the property and as part of that declaration, the constraints are encoded. How these constraints are defined and enforced is up to the particular project using the objects. At a minimum, code needs to be written which may not be available outside of the project to enforce the constraints.
> The SHACL solution is the one I will be going with for now.
Received on Friday, 13 March 2020 14:00:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 13 March 2020 14:00:01 UTC