...
An exception to these knowledge description resources are SHACL resources that have a special meaning for SHACL validators. They are used to validate that a certain RDF graph contains specific sub-graphs. This validation is also open world based, meaning that the validation only concerns those sub-graphs (triples) that are defined, others are invisible to the validator. The reason for this is the open world expansive nature of Linked Data: you should be able to validate a certain facet of a dataset without having to prune everything else from the data being validated.
The FI-Platform
...
Approach to Linked Data
...
Modeling
At this point we can move onto discussing the two primary model types on the FI-Platform. You should be aware that the implementation of models on the FI-Platform represents a subset and a specific implementation of the Linked Data ecosystem. The platform is by no means completely universal, and it is not universal, in other words it does not currently serve all the possible use cases the user base might have. Nevertheless, the platform will be expanded and refined gradually according to the needs of its user base.
The tool aims to produce universally applicable specifications covering a wide variety of use cases, meaning that the design choices have been guided by generality rather than specificity for a narrow set of needs.
Core Vocabularies (Ontologies)
primary aim of the tool is however fixed: it is meant for producing annotations which are used to semantically label data in the form of core vocabularies, and restrictions for validating labeled data in the form of application profiles.
When modeling a core vocabulary, you are essentially creating three types of resources: attributes, associations and classes - each with the structures provided by OWL 2 EL. With application profiles you are creating class, attribute or association restrictions provided by SHACL. For modelers with no previous background in OWL or SHACL modeling this might initially seem intuitive and straightforward (one might assume they are able to create models that look identical and are semantically equivalent to e.g. UML Class diagrams), but this is not true. It is important that you approach using the FI-Platform with the correct assumptions on what the platform is intended for. The FI-Platform is not meant for example for DDL-style database modeling or UML class diagram modeling. Instead, the approach with the FI-Platform is all about interoperability in the context of the European Interoperability Framework. Thus, the FI-Platform will be the correct tool for example:
when you need to add a knowledge layer (additional semantics, for example metadata) to your information architecture
when you need to manage or share knowledge (data enriched with embedded semantics)
when you need to harmonize data
when you need to create or maintain a knowledge base
when you need to increase the interoperability of data in your organization or between actors
when you want to manage data or knowledge based on open standards
Core Vocabularies (Ontologies)
The core vocabularies provide a structured framework for Firstly, the platform is capable of producing core vocabularies, which provide a structured framework for representing knowledge as a set of concepts within a domain and the relationships between those concepts. They are used extensively to formalize a domain's knowledge in a way that can be processed by computers. You will need core vocabularies in the following use cases (not an exhaustive nor ordered list):
when you need to annotate data, interfaces or models semantically
...
- SHACL (Shapes Constraint Language) is used to validate RDF data against specific defined "shapes" (conditions). The language is very expressive and difficult to generally map to simpler or more restricted schema languages such as JSON Schema and XML Schema. Limited subset of SHACL can be mapped though.
Modeling Core Vocabularies
...
- Schema. Limited subset of SHACL can be mapped though.
Modelling Core Vocabularies
Attributes
Attributes are in principle very similar to attribute declarations in other data modeling languages. The key differences from other major languages are:
As mentioned earlier, attributes are first-class citizens as they have identities. An attribute is defined once and can then be reused in multiple class definitions. A class does not "own" attributes used by it and they do not exist only within the namespace of the class nor is their life-cycle tied to the class.
Attributes can be used without being used "ownedinside" by a a class (unlike in e.g. UML). For an attribute definition, one can specify the class (
rdfs:domain) and/or data type (rdfs:range). The meaning of the data type is self-explanatory, but the class should not be confused as the attribute belonging to the chosen class. These definitions are related to inferencing only and will have no enforced effect if it is not used. Let us consider an attribute B which has class X set as the domain value and integer set as the range value. When a triple <A, B, C> is found, the A is inferred as being of type X and C being an integer literal. The domain and range values do not act directly as any kind of constraints. Without using inferencing their role is in guiding the correct use of the attribute resource.
...
Associations are similarly first-class citizens and can and should primarily be reused. Similarly to attributes, associations or their life-cycles are also not tied to any classes.
Associations can also be used without being "owned" by tied to a class and have domain and range definitions, but instead of the range expressing a datatype, it now expresses a class. This enables an association to label instances as being of certain type based on the usage of the association in data. The domain and range values do not act directly as any kind of constraints. Without using inferencing their role is in guiding the correct use of the attribute resource.
...
Associations can have hierarchies. This is an often overlooked but useful feature for inferencing. As an example, you could create a generic association called
hasAncestor that represents the group of all associations that connect people to their ancestors. You could then create sub-associations, for example hasFather and so on that depict a narrower definition of the ancestral relationship. Additionally, these hierarchies are not restricted to trees like in UML - polyhierarchies are allowed meaning that an association can have more than one super-association.
Associations can be declared as being equivalent to one another, with the similar logical consequences as with equivalent attributes.
Classes
Classes form the most important and expressive backbone of OWL. Classes can simply utilize the rdfs:subClassOf association to create hierarchies, but typically classes contain property restrictions - in the current FI-Platform case really simple ones. A class can simply state existential restrictions requiring that the members of a class must contain specific attributes and/or associations. Further cardinality restrictions are not declared here, as the chosen OWL profile does not support them, and cardinality can be explicitly defined in an application profile. In order to require specific associations or attributes to be present in an instance of a class, they must exist, as associations and attributes are never owned by a class, unlike in e.g. UML. They are individual definitions that are simply referred to by the class definition. This allows for situations where an extremely common definition (for example a date of birth or surname) can be defined only once in one model and then reused endlessly in all other models without having to be ever redefined.
...