Easy CICOD CRM configuration for Collective Access?

coldguy

Hi there. I'm just wondering if anyone else has tried this in their instance and if I could piggyback off of the works of others. I want to use an upper ontology to help organize my collection using CICOD CRM. If you have never heard of it before, I'd advise checking it out since it appears to use the longevity of Basic Framework Ontology (BFO) and apply it to museums and archival use.

If you prefer the official paper to read, here is the link: https://www.cidoc-crm.org/sites/default/files/cidoc_crm_version_7.1.3.pdf

Getting back to the topic: The CRM connects entities with Properties (using the P field designator). This is where the lightbulb went off. I know that you can create relationships in the system (https://manual.collectiveaccess.org/providence/user/dataModelling/relationships.html). So here is the question: before I go and manually recreate these relationships, has anyone attempted to find a way to import this into Collective Access? If so, could you share it with the community? Thanks in advance.

monica

I haven't come across this one yet, but on a quick scan I'd imagine the implementation of it in CA would we defined in a profile (https://manual.collectiveaccess.org/providence/user/dataModelling/Profiles.html)
That way it can be reused and extended upon by other people.
You can use profiles as add-ons to an existing system, where it adds new fields, relationship types etc. without deleting or modifying what you already have. So if it's just the relationship types you need to define, then a profile would be the way.

coldguy

monica Oh this is great thanks for linking to this article. The inevitable next question is outside of me viewing another profile and massaging it to meet CIDOC is there a handy get started video or document on creating your first profile that exists somewhere?

monica

No video and documentation is what I've linked you to there.

Other profiles are found in the the install directory of providence. Develop or php8 branch may have more to look at. There is also a separate repository of them https://github.com/collectiveaccess/InstallationProfiles/tree/main
An example of a partial install to load in an existing system is here https://github.com/collectiveaccess/providence/blob/dev/php8/install/profiles/xml/dacs_partial_redux.xml it's only got one relationshipType defined but gives you an idea.
To load a partial profile in you will need to use the command line caUtils found in support/bin. Type caUtils help for details.

coldguy

Thanks for the documentation I am going through the process right now and have a question about relationship types. In CIDOC they call these Properties in which you would describe one entity to another. The examples that I found on the wiki showcase these relationships being universal (where any field can connect to any other field). In CIDOC they are limited to one Entity to another within a certain subgroup.

Here is an example focusing on E1 (I am using shorthand to make it easier to read)
Outgoing Properties:
E1 P1 E41
E1 P2 E55
E1 P3 E62
E1 P48 E42
E1 P137 E55

There are also incoming properties (where E1 is on the right side) but to save time I will omit that from this post.

I understand the relationship type is more geared towards defining the element within the middle and to be used within a larger group, my question is how would I code this into a subgroup so that each Properly can only connect to their correct Classes (E in this example)?

monica

coldguy not sure I understand what you are trying to do.
In CA it works as below
If E1 is an entity of type individual and E41 is an entity of type organisation. Then P1 might be the relationship type employed where the forward term is E1 is employed by E41 and the backward term is E41 has employee E1. In the records for E1 and E41 you would see this under a set up related entity bundle. In the relationship type you can limit each side of the relationship to a given entity type (in this example right side is restricted to individual and the right to organisation)

coldguy

Ok, that makes sense; the CRM loves to restrict what can access which field, and from what you are describing unless I manually do this with every combination, it might not work. Since P1 will always be P1, having them treated separately might not be the way to go. Back to the drawing board.

monica

coldguy you don't have to restrict it. A relationship type can be put on any entity without restriction if you choose.

I do wonder if I'm not understanding what you're trying to do, as what I've seen described so far, CA does exactly that... It describes the relationship between 2 entities.