Define global properties only once and make relations more rigorous

[EOltmanns]

The definition:

fiaf:hasEvent a owl:ObjectProperty ;
    rdfs:domain fiaf:Carrier,
        fiaf:Item,
        fiaf:Manifestation,
        fiaf:WorkVariant ;
    rdfs:range fiaf:Event .

effectively means that the property can only applied to instances, that belong to all four classes at once. The domain is to be interpreted as the intersection of all named classes, see: https://www.w3.org/TR/owl-ref/#domain-def

This is probably not intended. Please consider a definition along these lines instead:

fiaf:hasEvent a owl:ObjectProperty ;
    rdfs:domain [
        owl:unionOf (fiaf:Carrier fiaf:Item fiaf:Manifestation fiaf:WorkVariant)
    ] ;
    rdfs:range fiaf:Event .

Also, since most event types only relate to one or two of the four classes Carrier, Item, Manifestation and WorkVariant per the Cataloguing Manual, it would be nice to make this explicit in the ontology. By transitivity, the same goes for descendant classes like fiaf:Activities and its subclasses.

There are more properties whose domains are currently defined as intersection of classes – probably uninteniotnally:

$ grep -e "rdfs:domain.*," ontology.ttl | wc -l
8

For the sake of discussion, I am going to open a pull request dealing with events and activities. However, most likely all 8 properties and descending ones need to be addressed, eventually.

[paulduchesne]

Thank you very much for bringing this up @EOltmanns, and reading this definition this does seem to be a very valid modification we should implement. I have found it interesting that when loading the ontology into WebVOWL it does seem to infer the anonymous union, but best to make this explicit. I will accept the initial pull request and then add a branch attached to this issue so I can deal with the others.

Thanks again for pointing this out!

Also, since most event types only relate to one or two of the four classes Carrier, Item, Manifestation and WorkVariant per the Cataloguing Manual, it would be nice to make this explicit in the ontology. By transitivity, the same goes for descendant classes like fiaf:Activities and its subclasses.

How would this be applied in such a case, do you means formerly expressing a union of all subclasses?

[paulduchesne]

Ah, I see what you mean with the more clearly defined connections with specific subclasses. This does tap into an interesting question I had which is that while there do seem clear delieations between what is meant by an agent for a workvariant and an agent for a manifestation, what about title and identifier - it does not feel useful to have a manifestationidentifier as a separate class. Although now I think about it, maybe in situations where an organisation has "reused" same identifiers in different context (ie there is an unrelated manifestation 60001 and an item 60001)?

[paulduchesne]

Quick reminder to assess ranges, as these also need to be "unionised"

[EOltmanns]

What ranges, do you think, need unionising? So far, I am only aware of this issue with regard to domains, ranges apparently always consist of a single class in this ontology. Or am I mising something?

[paulduchesne]

You are correct, looks like there are no multiple ranges! I just wanted to check to make sure.

As you may have seen, because each of the properties are defined repeatedly per relevant class and merged as part of the build process, defining union domains will require a rethink. This is probably best to happen now anyway, as otherwise any property changes (eg label) have to be made in multiple places.

[EOltmanns]

which is that while there do seem clear delieations between what is meant by an agent for a workvariant and an agent for a manifestation, what about title and identifier - it does not feel useful to have a manifestationidentifier as a separate class.

Well, I very much agree that there should be no manifestationidentifier or manifestationtitle class. I'm afraid my reasoning was partly flawed, so I'll try to work it out by example. The following is based on the assumption that the ontology should aid users specifically in making statements that comply with the FIAF cataloguing manual. This is because I assume that it would be easier for users to derive their own, more relaxed ontology from that if they so wish, than the other way around.

Let us look at the properties hasEvent, hasEventDate, and hasAwardName and consider the following statements for some non-trivial <a> and <b> in the domain and range of hasEvent, respectively:

<a> fiaf:hasEvent <b> .
<b> fiaf:hasAwardName "Most famous award for finest donkey" .
<b> fiaf:hasEventDate "2023-05-17Z" .

Here are some observations:

1. Given <b> such that the second statement is valid, then <a> can always be defined in such a way that all statements are valid, provided that <a> is WorkVariant or Manifestation, according to the cataloguing manual.
2. Conversely, if <a> is an Item or Carrier, there will be no way to define <b> such that all statements are valid according to the manual. For a Manifestation or WorkVariant <a>, however, <b> can always be defined such that all statements are valid.
3. Given any choice of <a> and <b>, regardless whether the first two statements are valid, the third one on its own will be valid except when a time span rather than a single point in time would be more appropriate. May be fiaf:hasEventDate should be replaced by some generic fiaf:hasTime (possibly subclassing from an existing ontology) that can express a single point in time, a certain period between designated start and end points in time, or a simple duration without reference to the calendar.

These observations can be formalised and enforced in the ontology by applying restrictions on inbound properties and deriving subclasses from outbound properties.

For the purposes of this argument, I consider hasEvent an inbound property, hasAwardName and hasDate outbound properties with regard to Events, respectively.

• As for hasAwardName, the manual only differentiates between the Events, it applies to, and the rest. Hence, the restriction of the domain to a dedicated subclass AwardsOrNominationsEvent.
• Assuming there was a property hasTime as outlined above, it would differentiate three types of events. Therefore, it would make sense to define corresponding subclasses CalendarEvent, PeriodEvent, and DurationEvent and subclass from those as appropriate.
• Finally, note that the inverse property of hasEvent is an outbound property, too. It happens to differentiate four subclasses of Event which may or may not be appropriate for subclassing depending on the cataloguing rules. WorkVariantEvent, for instance, is useful for subclassing because several activities are supposed to be associated with a WorkVariant but not with an Item.

Considering the property hasTitle, for instance, it does not make sense to define subclasses like ManifestationTitle, because the cataloguing rules do not impose restrictions on the titles of manifestations (or so I would guess). hasIdentifier is another story and should probably be defined as a functional property (another topic).

Does that all make sense to you?

[EOltmanns]

implement. I have found it interesting that when loading the ontology into WebVOWL it does seem to infer the anonymous union, but best to make this explicit. I will accept the initial pull request and then add a branch attached to this issue so I can deal with the others.

May be the problem can be demonstrated in WebVOWL when you add something like this to the ontology:

fiaf:WorkVariant owl:disjointWith fiaf:Manifestation .
fiaf:WorkVariant owl:disjointWith fiaf:Item .
fiaf:Manifestation owl:disjointWith fiaf:Item .

doisjointWith statements should probably be used sparingly, but these ones might actually make sense.

[paulduchesne]

The inclusion of an upper level of subclasses for events makes a lot of sense to me, given that attributing the types can be correlated quite easily (eg the workvariant has the award event, the carrier the acquired event).

These observations can be formalised and enforced in the ontology by applying restrictions on inbound properties

How would you approach enforcing these restrictions to prevent "illegal" statements from being made?

May be fiaf:hasEventDate should be replaced by some generic fiaf:hasTime (possibly subclassing from an existing ontology)

It does seem a good idea to abstract out the concept of time from being explicitly related to event, although event is the only instance where time-related concepts are present (except for duration, which is an extent).

it does not make sense to define subclasses like ManifestationTitle

It was pointed out at some point that there are manifestation and item only title types in the manual, but this did seem to be agonising over details.

[EOltmanns]

These observations can be formalised and enforced in the ontology by applying restrictions on inbound properties

How would you approach enforcing these restrictions to prevent "illegal" statements from being made?

Consider the following statements:

<subject_uri> a fiaf:Item ;
    fiaf:hasEvent [
        fiaf:hasAwardName "Most famous award for finest donkey"
    ] .

The ontology can prohibit this statement by making the domain of hasAwardName (i.e. AwardsOrNominationsEvent) a subclass of the union of ManifestationEvents and WorkVariantEvents, the latter two being what I call restriction classes because I define them as restrictions on the inverse property of hasEvent:

_:isEventOf owl:inverseOf fiaf:hasEvent .

<https://fiafcore.org/ontology/ManifestationEvent> a owl:Restriction ;
    dc:source "FIAF Cataloguing Manual 2.4.2"^^xsd:string ;
    owl:onProperty _:isEventOf ;
    owl:someValuesFrom fiaf:Manifestation .

<https://fiafcore.org/ontology/WorkVariantEvent> a owl:Restriction ;
    dc:source "FIAF Cataloguing Manual 1.4.2"^^xsd:string ;
    owl:onProperty _:isEventOf ;
    owl:someValuesFrom fiaf:WorkVariant .

fiaf:AwardsOrNominationsEvent rdfs:subClassOf [
        owl:unionOf (fiaf:ManifestationEvent fiaf:WorkVariantEvent)
    ] .

This is what I have implemented in the pull request for Events and Activities.

[EOltmanns]

Well, actually this still is not quite what I am after. I have now pushed a version with owl:allValuesFrom instead of owl:someValuesFrom and declared WorkVariant, Manifestation, and Item disjoint classes. I have compiled the ontology too, so may be you would like to have a look at it: https://service.tib.eu/webvowl/#iri=https://raw.githubusercontent.com/FIAF/modelling-workshops/dev-restriction-classes/ontology.ttl

[paulduchesne]

Thank you for these updates @EOltmanns, and sorry about the delay in getting you that script to compile the ontology independently. I can see a few instances where entities have now lost connection from the main tree, for instance condition and WorkVariantActivity probably need to be added as ranges to relevant properties, but otherwise it is looking good and "cleaner" than without the specification of entity.

[EOltmanns]

The colleagues I would normally ask to explain to me, how things are represented in WebVOWL exactly, are "not in reach" this week. Therefore, I am only guessing, but I have pushed another change that may or may not improve things. Can you see any difference at all?

By the way, I have only now found out that anonymous nodes are a bit of a nuisance with regard to automatic compilation of the ontology. They get random names that change on every compilation which would result in an extra commit on every push regardless whether the ontology has actually changed or not. That is why I have removed the anonymous inverse properties and used blank nodes instead in order to define restriction classes.

[paulduchesne]

@EOltmanns these updates have now fixed the narrowed classes from rejoining the main tree!

True re anonymous nodes, although I am now trigger ontology build on all updates given it is minimal overhead (although a side effect is that I think git is complaining about empty commits).

[EOltmanns]

Alright, as time permits, I will try to apply similar changes to other properties as well. Shall I go ahead and open a pull request against the new FIAFcore repo then?

[paulduchesne]

Please do! I would probably be keen to release a v1 at the end of the week as planned, but these logic enhancements are exactly what I had in mind as part of a v2 release.