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.