Issue 348: Using CRM

Starting Date: 
2017-10-06
Status: 
Proposed
Background: 

Posted by Martin on 29/9/2017

Dear All,

This may find your interest:

http://linked.art/model/profile/

Please note, that "simplifying the CRM" in the sense of recommending constructs not to use does not constitute another ontology, incompatibility or deviation from the standard. The standard is simply not prescriptive. I regard such simplification guidelines for specific communities as very useful.

Posted by Robert on 30/9/2017

Thank you Martin!

Yes, the intent is absolutely not to create a new ontology or prevent anyone from doing what they want with the CRM ontology and its extensions, but instead to find the minimum viable set of classes and relationships to use for the majority of use cases that we encounter around the community.  We are very careful not to deviate from the standard, which would create semantic incompatibilities between usage by adopters of the profile and those that do not (and hence the many questions over the past few months about some of the intended uses of things like Rights, Information Objects, and so on, to make sure that we /are/ following it whenever possible).

We would very much welcome any feedback.

Posted by Christian Emil on 30/9/2017

Dear all,
I have read through the profile and especially the list of usefull, abstract and unnecessary classes. .  It is not very controversial. It demonstrates the strength of CIDOC-CRM.  The profile can be useful as a starting point for a discussion about superfluous classes which we should make an issue.

Below I have some quick comments.

Best,
Christian-Emil

Most of the classes marked for deletion are the large variety of appellations of some sort or highly specialised classes from the early development of CRM (mark, inscription,title).

Some of the classes marked for deletion are hooks to be used for extensions (E27 Site for CRM Archeo).

The profile suggest to delete some of the subclasses of E73 Information Object
E29 Design or Procedure: “no use cases”
E31 Document “to be deleted”
E33 Linguistic Object
E36 Visual Item

It also suggests to delete E38_Image (subclass of E36 Visual Item)

The subclasses of E73 Information Object should be an issue in itself: E33 Linguistic object is defined as “Instances of E33 Linguistic Object can be expressed in many ways: e.g. as written texts, recorded speech or sign language.» and cover human linguistic utterances   E36 Visual Item covers what can be seen (by humans). But there are no subclasses for what we can hear or feel. The main reason may be the original objective of CRM to model what is stored in museum collections.

The class E83_Type_Creation is intended to model the process one find in systematic biology. In my view  this should be kept.

E9_Move has a comment ‘no use cases’. The class is very useful in describing provenance of objects. An argument against the class is that it only describes a transition from one place to another.

E78 Collection and E78 Curated Holding. There is an error in the CRM 6.2.2 definition from December 2016. The change form Collection to Curated Holding is not done throughout the document.

Posted by Martin on 30/9/2017

Dear Robert,

On 9/30/2017 12:27 AM, Robert Sanderson wrote:
> Thank you Martin!
>
> Yes, the intent is absolutely not to create a new ontology or prevent anyone from doing what they want with the CRM ontology and its extensions, but instead to find the minimum viable set of classes and relationships to use for the majority of use cases that we encounter around the community.  We are very careful not to deviate from the standard, which would create semantic incompatibilities between usage by adopters of the profile and those that do not (and hence the many questions over the past few months about some of the intended uses of things like Rights, Information Objects, and so on, to make sure that we /are/ following it whenever possible).
Yes, I have not suggested that you wanted to create a new ontology. I wanted to make clear that the CRM itself is no overt or hidden recommendation what should be documented, only how you should document something the CRM describes. This is a very frequent misunderstand, a major obstacle to use. Users read the CRM classes and assume they have to use them all. Then they get frightened, and make a smaller ontology, reinventing the CRM, instead of picking out those they need. I have even seen a PhD student in semantic Web technology that got such an advice from its supervisor.

Piking out classes and properties as a "profile" is absolutely good practice. It should, however, be specific enough to the use case.
For instance, if "Design or Procedure" has no use case, that means that conservation has not been considered. If "Move" has no use case, it means that object provenance has not been considered. That's fine, but should be made explicit in the beginning.

There is absolutely no construct in the CRM without use case. So, the statement should be "no use case in XXXX"

Some classes may be an overspecialization, this has to be discussed and respective classes be removed.
Some classes are definitely "abstract" in most use cases, i.e., the user will normally know more about the things she wants to describe, but they are extremely useful for querying.

Posted by Dan Matei on 2/10/2017

Friends,

On 30 September 2017 at 17:24, martin <martin@ics.forth.gr> wrote:


    Some classes may be an overspecialization, this has to be discussed and respective classes be removed.


Oh no ! Please do not remove anything !

I use almost all the CRM elements, in order not to loose nuances in my legacy databases (besides museum and library resources I have to model intangible resources - e.g. theatre productions). So I have to add elements from other ontologies and even – horror – to invent some more. I trust more the CRM elements than those I invent :-)

Moreover, even if some CRM elements are not used too much, they do not ask for food. So...

Please...

Dan

PS. You can establish Oskars for the "best" class of the year, the most popular property of the year, etc. And the "overspecialised" ones will earn no Oskar.

Posted by Robert on 2/10/2017

Hi Dan,

If the terms were moved to an extension, for example moving Site to the Archaeological extension, would then they would still be available for use but not add to the complexity of the base model.

I think there is some “food” they’re asking for, which is the cognitive cost of understanding them and when they should be used.  If that cost is high compared to the value (which I argue that it currently is), then the result is decreased usage of the model.  This “usability” cost is the primary driver for Linked Art – if we can do it once for the entire art domain, then every (art) museum or gallery has then had that cost pre-paid.

If you have data in real systems that _require_ the classes we’ve set aside, we’d very much like to discuss those with you off-list.

Hope that helps!

Posted by Christian Emil on 2/10/2017

Before Getty(?) send out the the profile to all arts museum, maybe one could go through the list once more and add a few central classes, move is one of them.
Best
Christian-Emil

Posted by Robert  on 2/10/2017

Hi Christian-Emil,

Could you provide some pointers to data that has Moves?  In our experience Move is theoretically important, but we could not find any museum that had Move activities that weren’t better described as a Transfer of Custody.

In particular:
• No history of internal movement between galleries / sites (which would not be a change of custody)
• No history of the actual movement of the object between institutions (e.g. for exhibitions), which would be better as a transfer of custody anyway.
• Disincentive to record these events or make them public as it encourages theft
• No real incentive to integrate shipping/tracking and descriptive systems

We’re very happy to move terms around, but only with good cause  In particular, two institutions that both require the class and have actual data to support it… preferably also with the intent to publish that data.

Posted by George on 30/10/2017

Dear all,

I don’t know of CRM encoded data with this information, but internal movement is traced in almost any major collections management system that I know of. The one I am most familiar with is the Emu system owned, now, by Axiell. It generates automatic internal movement records when registrars authorize the moment around the museum who carried it out and why. An example would be that the object is moved from storage to conservation lab for work and then back. This happened in the Museum of Islamic Art, so I guess it would be a use case for art objects. I also seem to recall some major projects of moving collections (perhaps of the Field Museum that uses Emu), where the work was to get everything from old storage A to new storage b. This was crucial provenance information because it helps them know why something may have gone missing and or what happened to it along the way (how was it packed, in what truck did it go). Here again what happened in reality was, I believe, an instance of move and not a transfer of custody acquisition or any such thing.
 

Posted by George on 3/10/2017

Dear all,

Addendum.

Sorry, missed an example related to the public/private question. It’s true that a museum would likely not want to do a public sharing of the internal moves of their objects. This is about use case context but okay (you can imagine just having an internal semantic network to match different systems and want to represent this data). A public use case of internal moves that you could want to share for research purposes would be move of object from storage to exhibition and back. This is a trace of the fact that an object really did go on exhibition (internally). It would be tracked by any museum using Emu and their internal moves module properly.

Posted by Martijn Van Leusen on 3/10/2017

Hi Rob,

I recently dealt with such a move, where some 1200 crates with archaeological materials were moved from their assigned shelf positions in storage building A, to temporary storage in building B, to their (hopefully) final destination to new shelf and stack positions in building C. All buildings were part of the same National Archaeological Museum of the Sibaritide (in south Italy). I was only responsible for part of the latter move (B to C), which required a lot of checking of what had been put where in building B by the moving company - resulting in one 'lost' crate that we still have to trace in our records - and some repackaging into new crates to allow placement in the new stacks of building C. In both building A and C, there was a system in place to record temporary removals of crates for specialist studies, and for permanently moving finds from one crate to another. Without such records chaos would quickly come to reign, as I have seen happen in other similar archaeology storage buildings....

Posted by Jane Sledge on 3/10/2017

Between 1999 to 2004, the National Museum of the American Indian moved over 850,000 items (archaeological and ethnographical) as well as 100,000 ethnographic images (photographs, glass plate negatives, etc) and archival materials from an old museum warehouse in the Bronx to NMAI’s newly built Cultural Resources Center in Suitland Maryland.  There was no transfer of custody for the movement of these items—it was a massive move.  We tracked via a barcoding system items being moved for digital imaging, a conservation review and if needed conservation, packing into appropriate sized boxes, the placement of the boxes into larger recyclable storage units which we called kivas, and the movement of the kivas using many trucks to the Cultural Resources Center.  We tracked the handlers of the items at every step of the way—who lifted the item off the shelf, who imaged the item, who did the conservation review, etc.  We also tracked the date and time that each of these steps occurred.  We then used the same process to unpack, reassess, rehouse, and move the items into their new compact storage unit locations.  This move is described at http://nmai.si.edu/explore/collections/moving/

We continue to track all items in our possession, on loan to us, and our loans to others with the same level of detail.  We use the location system to let visitors know what items are on view in our two museum facilities (DC and New York) and where else they may be viewed—on loan to other museums.  We know what items are in our conservation lab being prepared for exhibit, who moved the items there and when they were moved.

Tracking items is critical for accountability.  We have an inventory policy that requires us to find and account for 5000 randomly generated catalogue numbers a year as well as selections of archival items.

 

Posted by Robert on 3/10/2017

Dear Jane, Martijn,

Thank you for the descriptions!  Yes, we also (of course) track the locations of things internally … without knowing where things are there would be chaos, as you say.
However, for the purposes of publicly available Linked Open Data descriptions of your objects, would you publish descriptions of those moves on the web or are they internal only?

Or to put it another way … would you go to the effort of describing all of the move related activities in publicly available CIDOC-CRM?

Posted by Steve on 3/10/2017

Hi Rob
There is lots of potential research that could be done if the movement data was available from many institutions. For example on average how often do objects move, is there a relationship between moves and condition or material, how many moves does it take to organise an exhibit, what are the hidden costs of conservation interventions, what are the bandwidth requirements of RFID installations, should investment be made in specialist handling technology, who (and when) should training involve, breakage rates and so on. The additional effort required to make this data available is minimal, the potential for new insight large so yes I would make the data available.

Posted by Robert on 3/10/2017

hanks Stephen!

Can you point me to any data published in this way on the web today?  I think we all agree that it would be nice to have from a research point of view, but if institutions are unwilling to _actually_ do it (and our experience to date suggests that to be the case) then while the effort might be minimal and the potential large, the net result is still zero.

Posted by Jane Sledge on 3/10/2017

Robert, Stephen,
I may have responded to the question about location and inventory control data out of context.  We do not publish the locations of objects at the NMAI's Cultural Resources Center on our collections webpage.  We have published data about what exhibits or areas of the museums our objects are located in or were displayed in.  We often have visitors who ask us, "Where can I see 'insert tribal name here' objects?"  We would like to offer our visitors the ability to create their own unique tribally oriented museum tours.

Meetings discussed: