...
Attributes can be declared as functional, meaning in essence that only one value is allowed for a resource using an attribute. As an example, a resource describing an individual might use the attribute
age multiple times with different values (i.e. data might contain two triples: <somePerson, age, "50"^^xsd:integer> and <somePerson, age, "40"^^xsd:integer>). If age is declared as being functional, enabling inferencing will result in a contradiction, thus making the data invalid. Importantly, the functional declaration acts as a constraint on how the attribute can be utilised across the entire model.
Attributes can have hierarchiesbe declared as being equivalent to one another. This is an often overlooked but useful feature for inferencing. As an example, you could create a generic attribute called
Identifier that represents the group of all attributes that act as identifiers. You could then create sub-attributes, for example TIN (Tax Identification Number), HeTu (the Finnish personal identity code) and so on. Additionally, these hierarchies are not restricted to trees like in UML - polyhierarchies are allowed meaning that an attribute can have more than one super-attribute. Attributes can be declared as being equivalent to one another. This declaration means that if a property is assigned a value for an individual, any equivalent properties are inferred to have the same value for that individual as well. For example, if
birthYear and yearOfBirth are equivalent properties, and declaration means that if a property is assigned a value for an individual, any equivalent properties are inferred to have the same value for that individual as well. For example, if birthYear and yearOfBirth are equivalent properties, and it is known that an individual has a birthYear of 1990, then it can automatically be inferred that the individual's yearOfBirth is also 1990. This equivalence helps in maintaining consistency and ensuring semantic alignment between properties that are intended to represent the same concept or data point. Additionally, whatever is being said of either attribute will be applied to the individuals of the other attribute. As an example, if yearOfBirth is declared as functional, it will also mean that this restriction is imposed also on each individual using birthYear.
Some further guidance about attributes on the FI-Platform:
Attribute datatypes are by default XSD datatypes, which come with their own datatype hierarchy (https://www.w3.org/TR/xmlschema11-2/#built-in-datatypes). In core vocabularies it is usually preferable to define attribute datatype on a very general level, for example as
rdfs:Literal. This allows using the same attribute in a multitude of application profiles with the same intended semantic meaning but enforcing a context-specific precise datatype in each application profile.
If you have an entity that clearly could have an identity and you want to reference it as part of your model, it is not recommended to do this with an attribute. This is called the "things not strings" principle. As an example, if you model references a city as a structured part of an address, it is not recommended to use an attribute with the city name. This approach would lose the structural semantics as well as introduce difficulties related to localisation. Using traditional code lists gets rid of the localisation issue but not the lack of semantics.
Associations
The key differences for associations are as follows:
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 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 be declared as transitive, meaning that if resource A and B as well as B and C are connected with a transitive association X, then (after inferencing) also A is connected to C with the same association. This inferential behavior is a key feature of transitive properties, helping to extend direct relationships across linked chains of resources. While transitivity helps in deriving new connections, it is not a constraint that limits data entry but rather a rule for expanding understanding and relationships within the data.
Associations can be declared as reflexive, meaning that whenever the association is used in a triple, the subject of the triple is inferred to being also connected to itself via this association. In essence, if A is connected to B via a reflexive association X, inference will result in a new triple <A, X, A>. Reflexivity is an important feature in specific modeling contexts.
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.
Classes are not templates in the vein of programming or UML style classes but mathematical sets. You should think of a class definition as being the definition of a group: "instances with these features belong to this class". Following the Semantic Web principles, it is possible to declare a resource as an instance of a class even if it doesn't contain all the attribute and association declarations required by the class "membership". On the other hand, such a resource would never be automatically categorized as being a member of said class as it lacks the features required for the inference to make this classification.
Attributes can have hierarchies. This is an often overlooked but useful feature for inferencing. As an example, you could create a generic attribute called
Identifier that represents the group of all attributes that act as identifiers. You could then create sub-attributes, for example TIN (Tax Identification Number), HeTu (the Finnish personal identity code) and so on. Additionally, these hierarchies are not restricted to trees like in UML - polyhierarchies are allowed meaning that an attribute can have more than one super-attribute.
Some special guidance about using attributes in the FI-Platform core vocabularies:
Attribute datatypes are by default XSD datatypes, which come with their own datatype hierarchy (https://www.w3.org/TR/xmlschema11-2/#built-in-datatypes). In core vocabularies it is usually preferable to define attribute datatype on a very general level, for example as
rdfs:Literal. This allows using the same attribute in a multitude of application profiles with the same intended semantic meaning but enforcing a context-specific precise datatype in each application profile.
If you have an entity that clearly could have an identity and you want to reference it as part of your model, it is not recommended to do this with an attribute. This is called the "things not strings" principle. As an example, if you model references a city as a structured part of an address, it is not recommended to use an attribute with the city name. This approach would lose the structural semantics as well as introduce difficulties related to localisation. Using traditional code lists gets rid of the localisation issue but not the lack of embedded semantics.
Associations
The key differences from other major languages are:
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 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 be declared as transitive, meaning that if resource A and B as well as B and C are connected with a transitive association X, then (after inferencing) also A is connected to C with the same association. This inferential behavior is a key feature of transitive properties, helping to extend direct relationships across linked chains of resources. While transitivity helps in deriving new connections, it is not a constraint that limits data entry but rather a rule for expanding understanding and relationships within the data.
Associations can be declared as reflexive, meaning that whenever the association is used in a triple, the subject of the triple is inferred to being also connected to itself via this association. In essence, if A is connected to B via a reflexive association X, inference will result in a new triple <A, X, A>. Reflexivity is an important feature in specific modeling contexts.
Associations can be declared as being equivalent to one another, with the similar logical consequences as with equivalent attributes.
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.
Some special guidance about using attributes in the FI-Platform core vocabularies:
If you want to model qualified associations in the vein of Labeled Property Graphs or UML association classes, the primary recommended way is not to model this directly in the core vocabulary itself, but to create qualified associations (instances of the vocabulary association) in the data (with the desired associations and attributes) and use an application profile for ensuring that the instances will all have the required and/or desired qualifications. It is possible to model this also on the level of a core vocabulary by representing the qualified association with a class, but it will lead to different results in inferencing, as this will necessarily mean that the classes are not connected via the qualified association directly, but via two associations and a class representing the qualified association in between.
Classes
Classes form the most important and expressive backbone of OWL. The key differences from other major languages are:
Classes are not templates or blueprints in the vein of OOP, DDL or other common constructs but sets. Thus, when you define a class in the core vocabulary, you are defining the necessary and/or sufficient conditions for something to be labeled as belonging to the class (i.e. being of the "type" of the class). As an example:
A sufficient condition that you might model into the class
Human is having a Personal Identity Code (PIN), because it is only given to a subset of humans. Thus it is enough for an instance to have a PIN for it to be labeled as being human.
A necessary condition that you might model into the class
MarriedPerson is that they by definition must have a spouse. As you remember from the open world nature of Linked Data - an instance of a married person might not have information of his or her spouse because the information might not be available, but the mere declaration of the instance as a MarriedPerson has implications on what we can expect of the nature of this or any other such instance.
While classes can simply utilise the
rdfs:subClassOf association to create hierarchies with subclassing, there is a major thing to note: being sets, the classes can overlap and there is no implicit expectation in inferencing that they would not overlap. So, unless you explicitly state that two classes are not intersecting, they might overlap, meaning that there might be instances which belong to both classes. This is again due to the fact that we must be able to combine multiple facets of information easily together, meaning that for example an instance of Human might simultaneously belong to the classes MarriedPerson, Employee and Patient.
The attributes and associations added into a class (more precisely: used by a class) are used to specify the bounds of a class: what kind of features are to be expected of instances of a class. Again, specifying a class this way is not about constraints in the traditional sense but for machine inferencing - for validation you must use application profiles.
Similarly to associations and attributes, classes have equivalence declarations
...
, which is most typically used when combining or harmonizing datasets and aligning and simplifying models (as an example, one information system in an organization might use Employee and another StaffMember to describe the same individuals, there could be declared identical).
Modelling Application Profiles
...
With application profiles we use strictly separate set of terms to avoid mixing up the core vocabulary structures we are validating and the validating structures themselves. The application profile entities are called restrictions:
Attribute
...
And Association Restrictions
These restrictions are tied to specific attribute and association types that are used in the data being validated. Creating a restriction for a specific core vocabulary association allows it to be reused in one or more class restrictions. In the future the functionality of the FI-Platform might be extended to cover using attribute and association restrictions individually without class restrictions, but currently this is not possible.
...
SHACL is a very flexible language and due to this nature it allows the creation of validation patterns that might seem legit valid but are actually unsatisfiable by any instance data. As an example, the utilization of other class restrictions might lead to a situation where an attribute can never be validated as it is required to conform to two conflicting datatypes at the same time.
...
This section covers some generic recipes for modeling or model usage needs users might have. The recipes in this "cookbook" are by no means an exhaustive list of what is possible, and they will be expanded based on the discussion on needs of the FI-Platform user base.
Linked Data Toolset
-This section covers useful free or open source tools for creating and managing Linked Data.