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

Re: Designing my vocabulary

From: James Hudson <jameshudson3010@gmail.com>
Date: Fri, 13 Mar 2020 16:51:47 -0400
Message-ID: <CAEUVO9EfkGyV6ggVF+w9rxbUemZS-WBbBPNv91Y9Zp8SavHm9g@mail.gmail.com>
To: Martynas Jusevičius <martynas@atomgraph.com>
Cc: "schema. org Mailing List" <public-schemaorg@w3.org>
Hello Martynas,

On Fri, Mar 13, 2020 at 9:59 AM Martynas Jusevičius <martynas@atomgraph.com>

> 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?

As I and you already noted, this is not the correct path to follow. The
concept and implementation of an enforceable constraint should exist
outside of instances.

I don't think your SHACL example uses the actual range constraints.
> "4.3 Value Range Constraint Components" looks like what you need:
> https://www.w3.org/TR/shacl/#core-components-range

I did not attempt to provide a SHACL example.

> 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.

As a mere practitioner of this stuff, I am going to stay as far away from
Turtle and triples as I can, dealing with them only when I have to. It is
easier to sell json to people, which looks "normal" than it is to sell
stuff that looks like triples, which most have never seen before and would
be confused by. This is a marketing challenge to me as much as a technical


> 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 20:52:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 13 March 2020 20:52:12 UTC