Oddities in Our Current Models¶
About¶
In our current Fedora repository, there are several odd models that don’t align with the Philosophy Section. In order to think about and decide whether our philosophy in applicable to defined models and explore whether we should retroactively address, this document attempts to point out areas where our philosophy falls down.
NOTE: Some of the descriptions here go beyond structural metadata and include other forms of metadata stored in Fedora.
Collections are not pcdm:Collections¶
PCDM Models, the base ontology for all PCDM ontologies, defines four main classes:
pcdm:AlternateOrderpcdm:Collectionpcdm:Filepcdm:Object
Interestingly, our Fedora collections are instances of pcdm:Object rather than pcdm:Collection. A
pcdm:Object is defined as:
an intellectual entity, sometimes called a “work”, “digital object”, etc. that has descriptive metadata, access metadata, may contain files and other Objects as member “components”. Each level of a work is therefore represented by an Object instance, and is capable of standing on its own, being linked to from Collections and other Objects. Member Objects can be ordered using the ORE Proxy class.
A pcdm:Collection is:
a group of resources that has descriptive metadata, access metadata, and may link to works and/or collections. By default, member works and collections are an unordered set, but can be ordered using the ORE Proxy class.
While both classes are instances of ore:Aggregation, models and the
other ontologies treat these two classes differently. The models ontology defines properties such as
pcdm:hasFile which is only intended to be placed on pcdm:Object. The other models properties that
apply to either class have a domain of ore:Aggregation, meaning you can use them on either.
If the intention was to make these instances of pcdm:Object was to make them more flexible (let them contain files),
this decision to use pcdm:Object seems okay although I could not find an example of a collection with files. If
not, pcdm:Collection is more correct. If we keep these as instances of pcdm:Object we should consider
adding a rdf:type from another ontology that states these are more than pcdm:Object resources and are
something more close to the idea of a collection.
Use of pcdm:hasFile does not Adhere to rdfs:range Rules¶
Currently, pcdm:hasFile is used to link binary data streams to pcdm:Object resources. For instance, see
this page file
and the parent page resource.
Since pcdm:hasFile has a range of pcdm:File, the object of pcdm:hasFile should be an RDF resource
represented as node that should have a rdf:type of pcdm:File.
The link to the binary datastream should be on the pcdm:File and be done using a property such as fedora:hasBinary.