Upgrade of conditionsOfAccess to Class and ObjectProperty

[williamsonrichard]

Currently, rico:conditionsOfAccess is a datatype property. I think it would be very useful, and more in line with much of the rest of RiC-O, to instead introduce a class ConditionOfAccess and an object property hasConditionOfAccess with range this class, or at least offer this as an alternative.

[florenceclavaud]

Hi @williamsonrichard, I think we'll keep the datatype property, just like for rico:identifier, rico:name, rico:date, rico:recordResourceExtent, etc.. Just to help implementers who would have to process legacy archival metadata, and whose systems would not be able yet to assign and manage unique, persistent, identifiers to these entities (which would then result in a lot of blank nodes when processing the metadata, for the instances of the RiC-O classes generated). The institution where I work has such a system, and obviously it is not rare. It does not mean that RiC-O should not provide a more precise way to handle conditions of access. As concerns this property, and the rico:conditionsOfUse one: one method could be to simply use the existing rico:isOrWasRegulatedBy + an instance of rico:Rule, that could be linked to a rico:RuleType and have its own description. Or, maybe better but more complicated, as specific conditions of access or conditions of use often result from a rule, we could, as you suggest, create 2 classes that could serve as intermediate nodes between the Record Resource and the Rule(s).

[williamsonrichard]

Hi @florenceclavaud, absolutely, I should have been more precise: by 'upgrade' I meant to do exactly as has been done with rico:date for example, where one keeps the datatype property but marks it with the same kind of scope note; but to in addition allow for a class implementation with a corresponding object property, just as has been done with rico:Date. I would think that privacy/conditions of access will in many cases be sufficiently important and complicated for archival institutions that the flexibility that a class offers will be desirable. One can find for example 'privacy ontologies' concerning GDPR and so on out there which a user might wish to connect to.

Good ideas in your second paragraph, I had not thought about implementing it by means of a new sub-property of rico:isOrWasRegulatedBy and a sub-class of rico:Rule, that is indeed one possibility; regarding your final sentence, it might be sufficient to introduce a new sub-property or two of rico:isRuleAssociatedWith.

[ivozandhuis]

I would suggest to leave the ontology as-is and use the existing Rule-class and its properties as suggested above. This pattern is flexible (what is 'access' and 'use' anyway and there might be conditions that are both or something else). See the following example:

@prefix rico: <https://www.ica.org/standards/RiC/ontology#>.

# ---- Archival material
:rec-01 a rico:Record ;
    rico:isOrWasRegulatedBy :gdpr-accessrule-2025 ;
    rico:isOrWasRegulatedBy :gdpr-userule-2030 ;
    rico:hasInstantiation :inst-01 ;
    rico:hasInstantiation :inst-02 .

:inst-01 a rico:Instantiation ;
    # the paper thing
    rico:isOrWasRegulatedBy :preservation-rule-01 ;
    rico:isOrWasRegulatedBy :preservation-rule-02 .

:inst-02 a rico:Instantiation ;
    # the digitized paper thing
    rico:isOrWasRegulatedBy :software-01 .

# ---- Rules
:gdpr-accessrule-2025 a rico:Rule ;
    rico:hasOrHadRuleType :conditionOfAccess ;
    rico:hasOrHadTitle [
        a rico:Title ;
        rico:textualValue "Not accessible according to GDPR."
    ] ;
    rico:hasEndDate [
        a rico:Date ;
        rico:normalizedDateValue "2025-01-01"^^xsd:date ;
    ] ;
    rico:isOrWasEnforcedBy :city-archivist-amsterdam .

:preservation-rule-01 a rico:Rule ;
    rico:hasOrHadRuleType :conditionOfAccess ;
    rico:hasOrHadTitle [
        a rico:Title ;
        rico:textualValue "Not accessible because digitized."
    ] ;
    rico:isOrWasEnforcedBy :city-archivist-amsterdam .

:gdpr-userule-2030 a rico:Rule ;
    rico:hasOrHadRuleType :conditionOfUse ;
    rico:hasOrHadTitle [
        a rico:Title ;
        rico:textualValue "Must be anonymized before publication."
    ] ;
    rico:hasEndDate [
        a rico:Date ;
        rico:normalizedDateValue "2030-01-01"^^xsd:date ;
    ] ;
    rico:isOrWasEnforcedBy :city-archivist-amsterdam .

:preservation-rule-02 a rico:Rule ; 
    rico:hasOrHadRuleType :conditionOfUse ;
    rico:hasOrHadTitle [
        a rico:Title ;
        rico:textualValue "Not allowed to make a photocopy because of bad material state."
    ] ;
    rico:isOrWasEnforcedBy :city-archivist-amsterdam .

:software-01 a rico:Rule ;
    rico:hasOrHadRuleType :conditionOfAccess ;
    rico:hasOrHadTitle [
        a rico:Title ;
        rico:textualValue "This file can be opened with a PDF-Viewer, complying to specification XXX."
    ] .

# ---- RuleTypes
:conditionOfUse a rico:RuleType .

:conditionOfAccess a rico:RuleType .

# ---- Agent
:city-archivist-amsterdam a rico:Position ;
    rico:hasOrHadAgentName [
        a rico:Name ;
        rico:textualValue "City Archivist of Amsterdam"@en ;
        rico:textualValue "Stadsarchivaris van Amsterdam"@nl ;
    ] .

[florenceclavaud]

Good example, @ivozandhuis! Could be a perfect one to put in the future 'examples' folder of RiC-O 1.0.

[wildit]

For the moment I would also leave it as it is. Ivo's examples show that there is already quite a lot of flexibility. I suggest to re-discuss rico:Rule as soon as we start to look into the alignment with PREMIS and the PREMIS Rights section. I have the impression that we align already quite a bit with PREMIS in this regard.

[williamsonrichard]

Very nice examples indeed! But what I felt in raising the issue was that a) conditions of access is already defined in RiC-CM (A08), and b) there is a datatype property for it. In that situation (i.e. if the concept of conditions of access is important enough and well-defined enough for a) and b) to hold), in my opinion, an object property approach should be defined as well, because people may well wish to do exactly the kind of thing that Ivo did, and e.g. for inter-operability reasons, we would wish that different institutions have a common semantics for it. RiC-CM refers to both 'model-based text' and 'free text' for A08, and 'model-based text' should surely refer to individuals of a class. Moreover, although maybe not universally, RiC-O has quite generally followed this pattern of allowing for both a datatype and an object implementation.

That is to say, as I see it, it is not so much a question of enough flexibility, but whether there is too much flexibility :-).

One way to do it that directly follows Ivo's approach would of course be to actually introduce the individuals 'conditionOfAccess' and 'conditionOfUse' of the class RuleType in RiC-O. But this alone does not really fit the pattern of what RiC-O has done elsewhere; I think one would ideally like a more direct way to refer to Conditions of Access as 'model-based text'. But perhaps one could combine introducing those two individuals with introducing the following.

Class: ConditionsOfAccess
  SubClassOf: Rule, hasOrHadRuleType value conditionOfAccess

This formalises exactly what Ivo does in his examples, so that we can still do exactly as he does, but we have the benefits of a common, defined semantics for it. Of course such a class could later be linked with PREMIS, etc.

One could choose too to introduce an object property hasConditionOfAccess which is a sub-property of isOrWasRegulatedBy and which has range this new class ConditionsOfAccess, but I agree that, whilst this might be nice and be quite consistent with what RiC-O does elsewhere, it is not necessary as such; isOrWasRegulatedBy itself does do the job.

[florenceclavaud]

I was also as I said thinking of adding some classes and object properties. But we need to postpone the decisions on this to after RiC-O 1.0 release. For now most of RiC-O implementations - as far as I know at least - can handle access rules (or any rule that applies to Record Resources) using what RiC-O already provides, just like @ivozandhuis suggested, or extending RiC-O. I know this is not a satisfactory answer but we do not have enough time to think of that now, not to mention that our work with the PREMIS editorial committee has not yet dived into a detail analysis. I will therefore mark the issue with the "after RiC-O 1.0" milestone.

[williamsonrichard]

No problem, that is fully understandable! Sounds good!