Property Paths

[joschne]

Need

There is a need for Property Paths in OntoME. A property path is an ordered list of properties and classes, describing a path through the graph of the conceptual data model. Such paths are useful in various use cases.

Use cases

Alignment of Shortcuts

The same feature/attribute/property of an entity can be modeled with different property paths.

For example, the property sdhss:P20 has issue is a shortcut for the more fully developed property path F18 Serial Work -> R10 has member (is member of) -> F19 Publication Work -> R23i was realised through (created a realisation) -> F30 Publication Event -> CLR6i should be carried by (should carry) -> F3 Manifestation Product Type.

Currently in OntoME, the alignment of a property to a property path can't be expressed in a structured way. Neither is it possible to align two property paths.

Expressing such alignments would allow to explicitly express semantic relationships between properties and paths, which improves the documentation of an onotology.

If exposed by OntoME through an API (json or rdf), the alignments can be used by other services for its own logic. See below.

Serialization of Shortcuts in RDF

On one hand we need complex conceptual data models to create information about a complex reality in reusable way. On the other, for the identification, readability and interoperability of the information, shortcuts are helpful. It may, for example, make sense to flatten the path E21 Person > crm:P98i was born > sdh:P6 took place at (was place of) > C13 Geographical Place
to the wikidata shortcut property place of birth and add an additional triple for it.

Types of Types in Toolbox

The geovistory toolbox allows to create information based on profiles exposed by OntoME. While users can't change the Ontology (classes and properties), they can create types. This can lead to vast list of types that are hard to manage in the UI. With types of types we improve the UX by restricting some types as ‘suitable for’ another type through a path.

Example:
The class E54 Dimension comprises quantifiable properties such a length of 5 cm or a weight of 2 kg.

The dimension has two outgoing properties in order to express the dimension:

• E54 Dimension > P90 has value > crm:E60 Number
• E54 Dimension > P91 has unit > crm:E58 Measurement Unit

With these properties we can express (turtle pseudo code):

 <:dimensionA> <:hasValue> "5" .
 <:dimensionA> <:hasUnit> "cm"

While this is sufficient for the data publication, the high level of abstraction in the model causes a problem for the user experience when creating the information, because of the high number of kinds of dimensions and measurement units. In addition to length (mm, cm, m, km, ect.) and weight (mg, g, kg, etc.) there are area, volume, monetary amount, duration and, depending on the discipline, many more. The high number of measurement units leads to a long list of options in a select dropdown, leading to confusions by the users.

As a solution we envisage to visually filter instances of E58 Measurement Unit (like cm, m, km) by a Dimension Kind.

Therefore the dimension has a third outgoing property:

• E54 Dimension > crm-sup:P25 has dimension kind > C27 Dimension Kind

These Dimension Kinds allow to express that a Dimension is of kind "length", "weight" or "volume" etc.

In order to filter the options of measurement units for the kind "length" in the Toolbox UI, we have to express that the E58 Measurement Unit "cm" is suitable for C27 Dimension Kind "length" through the property path crm:E58 Measurement Unit > P91i is unit of > E54 Dimension > crm-sup:P25 has dimension kind > C27 Dimension Kind

Application Profiles

There are information systems or virtual research environments that utilize a conceptual reference model to generate a user interface based on it.

Examples of such systems include WissKI, Researchspace, (Arches?), which have their own path builders to define application profiles. In these path builders, for instance, the path from person to birthdate is defined, resulting in the creation of a birthdate field in the user interface for a person.

Property Paths in OntoME correspond to this path builder. When the stored paths of a profile are published via API, such systems can delegate the creation of such application profiles to OntoME. Furthermore, these application profiles are published/documented in a central location.

[atterebf]

Another pathbuilder is the Zelig web application .
The produced paths are published on the SARI Documentation Website, e.g. the Person Reference Data Model

[mquantin]

From my understanding of the terminology "property path" is for sparql queries while "chained properties" is for owl definition (and inferences).

Be aware that chained properties is a Work in progress at the w3c: https://www.w3.org/2007/OWL/wiki/FullSemanticsSubPropertyChains

So maybe the discussion should be renamed "chained properties" as it is about definition and not querying in ontoMe.
CMS like wissKI or researchSpace do path building as they are not defining ontologies but using/querying it.

[joschne]

I am no expert in OWL. Can you please help out with a clarification?

In your question, you made an example of a property chain:

crms:P1_has_conceived owl:propertyChainAxiom
( crm:P94_has_created crm:P33_used_specific_technique crm:P31_has_modified ).

Is it correct to say, that the list ( crm:P94_has_created crm:P33_used_specific_technique crm:P31_has_modified ) contains items of owl:ObjectProperty?

We are seeing a need for a list of altering owl:Class and owl:ObjectProperty:

• The property sdhss:P20 has issue is a shortcut for the more fully developed property path F18 Serial Work -> R10 has member (is member of) -> F19 Publication Work -> R23i was realised through (created a realisation) -> F30 Publication Event -> CLR6i should be carried by (should carry) -> F3 Manifestation Product Type.

The purpose of defining the owl:Class is to narrow down to a specific subclass of the domain/range of the owl:ObjectProperty.

Would the property chains as specified here (https://www.w3.org/2007/OWL/wiki/FullSemanticsSubPropertyChains) allow such a alternating list?

[mquantin]

terminology:
property path: https://www.w3.org/TR/sparql11-property-paths/

1. gather several properties with operator in a sparql query.
2. Nothing is defined in the ontology. It is only a set of query facilities .
3. It's a temporary shortcut.
4. Several operators allow creating complex path. see https://en.wikibooks.org/wiki/SPARQL/Property_paths

property chain: https://www.w3.org/2007/OWL/wiki/FullSemanticsSubPropertyChains

1. gather several properties in the definition of the ontology.
2. New inferences are computed.
3. It is a permanent definition of a shortcut. It impacts the whole ontology, all the queries and uses of the rdf database.
4. As far as I know, the path has to be defined with a list of properties, no operators are allowed.

You're right, in my example, the list contains only owl:ObjectProperty.
The path doesn't alternate owl:ObjectProperty and owl:Class
This is the way a property path is defined in SPARQL
This is also the way a property chain is defined in OWL

Why?
Many considerations might help to understand, some of them:

• a list of class only is too open and has no semantic meaning
• a list of properties only does the job 😄 !
• in SPARQL property path, if you write down the class in-between, then it's not a property path anymore! (but a "normal query" 😄 )
• in OWL the class may be inferred from the property domain/range. So if you use an objectProperty, then the "connected" entities get the class defined in the domain/range of the objectProperty. see here for example: https://stackoverflow.com/a/44410454/4887859
• in OWL property chain, if you need to match only a specific subclass of the domain/range (inference is not precise enough), then it means that your property semantic meaning is unclear, then you better should define a subproperty of that property!

[joschne]

Thank you for these clarifications. I have a doubt about this:

a list of properties only does the job 😄 !

In order to define a property chain in the UI of OntoME, you have to start from a class. Let's assume we want to express this chain:

F18 Serial Work -> R10 has member (is member of) -> F19 Publication Work -> R23i was realised through (created a realisation) -> F30 Publication Event

Steps

1. select class F18 Serial Work
2. select outgoing property R10 has member (is member of) amongst this list of properties
3. select class F19 Publication Work and NOT frbroo:F1 Work. F19 Publication Work is a subclass of frbroo:F1 Work.
4. select incoming property R23i was realised through (created a realisation). The range of this property is F19 Publication Work and NOT frbroo:F1 Work.

By selecting a subclass of the property domain in step 3, we have access to the property in step 4. For this reason I think, an alternating list of classes and properties is required to build such a chain.

This does not prevent us from serializing such a chain as a property chain in OWL, as proposed here https://www.w3.org/2007/OWL/wiki/FullSemanticsSubPropertyChains, by omitting the classes.

Does this make sense to you @mquantin ?

[mquantin]

mmmmh classes are not needed due to the way inferences are computed.
This is the misunderstanding.
You write:

By selecting a subclass of the property domain in step 3, we have access to the property in step 4

(and some other phrases with the same logic order)
But in OWL the reasoner works the other way:
you don't "access to properties" by "selecting a class" (these are your words)
but classes are inferred from the selected property.

Simple example with a property P such as (from here :
P rdfs:domain D
P rdfs:range R
statement s P o implies s rdf:type D and o rdf:type R.

Now let me use your example without the classes:
itemA -> R10 has member (is member of) -> itemB -> R23i was realised through (created a realisation) -> itemC
It can be inferred that:
itemA rdf:type frbroo:F15 Complex Work
itemB rdf:type frbroo:F30 Publication Work
itemC rdf:type frbroo:F30 Publication Event

It looks fine, doesn't it?
(Inferred from the domain and ranges of the properties)
That's why classes are not needed in property chains.

If you need itemA to be specifically a F18 Serial Work and not any F15 Complex Work then you need to define and use a new property with that specific domain.

Hope it helps.

[joschne]

Yes, perfect! I understand. We just talk about different use cases: You talk about the usage of a property chain (by a reasoner), I talk about the creation of a property-class-path in OntoME, that can be used by systems like Geovistory or WissKI to create a GUI to edit data. As I wrote, we can still serialize (export) the property chain according to the OWL draft mentioned above.

[mquantin]

ah ok.

• I was talking about the definition of property chain, written in owl, that can be used by a reasoner or wherever.
• If you want a property-class-path in OntoME. Then you need classes indeed (and ontoME !)
  I don't know about WissKI and Geovistory