Incorrect use of rdfs:domain

[IS4Code]

I have noticed some properties in the filesystem ontology akin to this:

:lastAccessedOn
    a owl:DatatypeProperty, owl:FunctionalProperty ;
    rdfs:domain :Directory, :File ;
    rdfs:range xsd:dateTimeStamp .

As is it currently written, this implies that the domain of :lastAccessedOn is the intersection of classes :Directory and :File, not their union.

Per the RDF Schema 1.1:

Where a property P has more than one rdfs:domain property, then the resources denoted by subjects of triples with predicate P are instances of all the classes stated by the rdfs:domain properties. Any entity that has this property is simultaneously a file and a directory.

The solution would be to specify a class that both :File and :Directory are subclasses of. I think it would be best to add some overarching class like :FileSystemEntry and use that, since even volumes, links etc. might have these attributes.

[plbt5]

I fully support @IllidanS4 's review comment. Regarding solution, although S4 's suggestion is certainly valid, I suggest the use of a blank node to improve terseness and readability, as follows:

:lastAccessedOn
    a owl:DatatypeProperty, owl:FunctionalProperty ;
    rdfs:domain [
    	owl:unionOf (
            :Directory :File
        )
    ] ;
    rdfs:range xsd:dateTimeStamp .

[plbt5]

Apart from the above, is it really the intention to apply rdfs:domain and rdfs:range in the way that it is specified? Its application is often confused as setting a data restriction, as opposed to its actual function that is to infer something to be of a certain class. In this example, with the following data:

<A> :lastAccessedOn <B> .

the function of the rdfs:range statement would be to infer that

<B>  rdf:type xsd:dateTimeStamp .

I assume, though, that the authors expected an error message of some sort in case <B> did not actually denote an xsd:dateTimeStamp. However, in order to enforce this behaviour one would apply a SHACL statement to specify that particular data constraint.