Re: Designing my vocabulary

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 13:44:39 UTC