Fixity class in ontology

[acoburn]

Somewhat related to https://jira.duraspace.org/browse/FCREPO-1343, I have a question about Fixity class in the repository# ontology. The fcrepo code appears to use the Fixity class from the Premix namespace and not from the repository:Fixity class. Should this class also be removed from the repository# ontology? (A similar question applies to the hasFixity property). This would also involve changing the range of various properties to http://www.loc.gov/premis/rdf/v1#Fixity.

[awoods]

@acoburn, if we are not using repository:Fixity in the codebase, then removing it from the ontology makes sense. Have you done a comprehensive search in the code?

[ajs6f]

+1 to the change, and as a sidebar, it's probably getting to be time that we develop some kind of public policy towards PREMIS, especially if we are going to import it into the ontologies.

[escowles]

I definitely think we should get the ontology and the code in sync on what kind of fixity class we want to use. The premis:Fixity class description (http://id.loc.gov/ontologies/premis.html#Fixity) looks fine to me. And I think there are other places where we are using PREMIS already (premis:hasOriginalName and premis:hasSize) and other places where we may add it soon (audit).

So I am generally in favor of using the PREMIS classes and properties where they make sense and not inventing our own slightly-different notions.

@ajs6f: do you have any issues with embracing PREMIS? Are there other vocabularies we should consider instead, or significant differences between the PREMIS and Fedora notions of fixity, file characteristics, auditing, etc.?

[ajs6f]

@escowles By no means-- I just want to be open about it and make sure the community knows where we're going.

[awoods]

It looks like we use a few Fedora-specific predicates relating to Fixity:
https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel/src/main/java/org/fcrepo/kernel/RdfLexicon.java#L127-L135

But repository#Fixity does not appear to be used in the codebase. Let's remove it from the vocabulary.

[acoburn]

@awoods -- that is what I saw, too. As far as I can tell, the only use of anything Fixity-related is in the main fcrepo4 codebase, and there it uses the PREMIS namespace.

[awoods]

Other Fedora-specific fixity predicates are used here:
https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-impl/src/main/java/org/fcrepo/kernel/impl/rdf/impl/FixityRdfContext.java#L77

[acoburn]

Should we try to get this change in before the 4.1 release?

[awoods]

It seems like a small enough update to go in with the other ontology changes. So, yes. Interested?

[acoburn]

Yes, I have some time tomorrow

[awoods]

👍

[acoburn]

The other question on this topic relates to the isFixityOf property. It is basically the inverse of hasFixity (which was removed in the above PR). It is also not used in the fcrepo4 codebase, but there is no such property in the premis namespace.

I am inclined to remove it, but I'd like to hear from others.

[escowles]

We don't link from the fixity triples back to the resource being checked. Since we have this property, I assume we once did or at least thought we should. Maybe this was something that changed with the fcr:content/fcr:metadata inversion?

Since we're not using it, I think we should remove it. If we decide that we want to make that link explicit, we can decide at that point what predicate would be best to use for that.

[ajs6f]

+1

[awoods]

isFixityOf should be removed, but hasFixity should not, as it is used in FixityRdfContext.java:
https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-impl/src/main/java/org/fcrepo/kernel/impl/rdf/impl/FixityRdfContext.java#L82

[acoburn]

No, that is not correct. the hasFixity uses the premis namespace: https://github.com/fcrepo4/fcrepo4/blob/21572a273c9d94ed7e0e6811e4553ac99245264e/fcrepo-kernel/src/main/java/org/fcrepo/kernel/RdfLexicon.java#L124

[awoods]

Right you are, @acoburn. Thanks.
So in addition to removing hasFixity from the Fedora vocabulary (as this PR does) there is agreement that isFixityOf should also be removed.

[acoburn]

I updated the PR so that isFixityOf has also been removed

[acoburn]

Resolved with c8c1aca