For full text search please use the '?' prefix. e.g. ? Onboarding

SHACL

From Shex
Go to text →

Implementations

Examples

Features

  • "SHACL uses CWA in its reasoning"

  • "SHACL uses RDFS subclassing mechanism. When you create SHACL models you define classes and more specific subclasses. Additionally, you can separate Node Shapes from classes to define application specific views.Take a look at this blog to understand differences between classes and node shapes... With SHACL, you can deactivate constraints that you don’t need or can’t agree with. This is done declaratively, using the standard so it is unambiguously clear what aspects of the models you are using and what aspects you are not using."

  • "SHACL is a semantic constraint language, which is quite useful as a guard for updates to a triple store. Because SHACL is less concerned with meaning and more concerned with structure, many object-oriented ontologists prefer it to OWL for defining their classes."

  • SHACL was strongly influenced by Spin and can be regarded as its legitimate successor

  • "Shacl popped up because people wanted to have something that operstes over their A-Boxes without slowly dragging their entire modeling and data storage into the T-Box. That's why they don't want the "description logic perspective", as it automatically leads down that "no instances, just theories" rabbit hole."

Examples

Constraint Types

  • Structural Constraints: Ensuring that data adheres to a specific schema or model, such as required properties, permissible property values, or specific class hierarchies.
  • Value Constraints: Limiting the values that can be taken by properties, including data types, value ranges, and pattern matching.
  • Cardinality Constraints: Defining the minimum and maximum occurrences of properties.
  • Logical Constraints: Applying logical conditions to properties and values, such as equality or inequality, and combinations thereof through logical operators.

Comparisons

From Shex
Go to text →

ShEx vs SHACL

  • ShEx has the operators | to represent “oneOf” while SHACL has xone to represent exactly one.
  • ShEx has been implemented in a variety of programming languages and RDF libraries: Apache Jena, Ruby, Javascript, Haskell, and Python (see section 4.3). In the case of SHACL, most implementations are based on Apache Jena and there is an implementation based on Javascript (see section 5.2) although there are some implementations appearing in other systems like rdf4j. Most ShEx implementations are non-commercial and have been developed mainly by individual projects. SHACL has a mature commercial implementation, bundled with the TopBraid suite of products, which offers a rich user interface for editing SHACL-based data models. Although TopBraid is a commercial product, SHACL’s implementation is based on a separate open source library maintained by TopQuadrant. SHACL is also integrated in the free edition of TopBraid Composer.

Schema vs Constraints

  • The designers of ShEx intended the language to be like a grammar or schema for RDF graphs. This design was inspired by languages such as Yacc, RelaxNG, and XML Schema. The main goal was to describe RDF graph structures so they could be validated against those descriptions.

In contrast, the designers of SHACL aimed at providing a constraint language for RDF. The main goal of SHACL is to verify that a given RDF graph satisfies a collection of constraints. In this sense, SHACL follows the Schematron approach, applied to RDF: it declares constraints that RDF graphs must fulfill. Just as Schematron relies strongly on XPath, SHACL relies strongly on SPARQL

From Spin
Go to text →

SPIN vs SHACL

  • SHACL offers much greater flexibility w.r.t. the application target of constraints (and rules). While SPIN is limited to classes, SHACL shapes can be applied to either classes or sets of nodes derived by other means. See the various target mechanisms in SHACL, including the custom targets from the Advanced Features document.
  • "SHACL should be regarded as the next generation of SPIN. Learn how they compare."

Resources

  • https://archive.topquadrant.com/shacl-blog/
    • "There are many ontologies in OWL which are really glossaries or taxonomies of terms. They do not define classes in terms of properties of their members. In other words, they do not contain schema or data definitions. They simply describe classes as vocabulary terms. You can easily identify such “ontologies” because you will see no OWL restrictions or domain/range statements. Instead, you will see synonyms and other annotation properties. In this case, recognize them for what they are and translate them to SKOS and/or develop a small ontology of your own to express this information. There is no value in keeping these terminologies in OWL nor in having them in SHACL."
  • https://archive.topquadrant.com/technology/shacl/

References

Backlinks