Vocabulary for museum objects

Omeka S
1

I’m looking for a good vocabulary for modelling museum objects. Museum objects rarely have titles and often we have no idea who the creators are either, but we do have a lot of fields, some of which are governed by thesauri, and some of which are more descriptive for humans to read. The types of property we would want to use include:

  • Object name (what is the object, e.g. a spoon, a board game, an axe head)
  • Material (what the object is made from, e.g. copper, wood, ceramic)
  • Physical description (a short sentence describing the object)
  • Production place (where was the object made)
  • Production period (when was the object made)
  • Start and end dates, with levels of approximation, for the production
  • Subject of the object (e.g. what or who is depicted in a painting)
  • Inscriptions (which may need transliterated and translated version also)
  • Associations (e.g. this object is used in a religious context)
  • Dimensions of object
  • Field collection method (for archaeology)
  • Field collection place (i.e. where was an archaeological object found)
  • Typology (specialist categorisations, e.g. Dragendorff classifications for Samian ware)
  • Technique (how the object was made)
  • Previous owner

Does anyone have any recommendations.

N.B. I am talking about the “vocabulary” in Omeka, i.e. the field names. I’m not seeking recommendations for suitable thesauri, subject terms or controlled vocabularies.

Thanks,
Matthew Phillips, Durham University, UK

2

Many, many of our museum friends use CIDOC-CRM. On the thesaurus front, you should check out the Value Suggest module, which includes Nomenclature and many of the other possible authorities that you might need.

1 Like
3

I’ve loaded the CIDOC-CRM vocabulary and it certainly seems to cover a lot of what we need, but some things are still problematic.

It would be possible to make an Item in Omeka for a statue (for example) which would be classed as E22 Human-Made Object. One could attach properties to the item to describe what it consists of in terms of materials (P45 “consists of” with range E57 Material).

One could either give the material information as a literal string (e.g. “bronze”) or we could have further Omeka Items of class E57 Material for “bronze” and any other materials we need. You would then link from the statue item to the bronze item via the P45 “consists of” property.

That is all OK, and I can see many advantages to being able to retrieve materials as items, and see bronze objects linked from the Item for bronze.

But CIDOC-CRM regards the Production of an object as a class in its own right also. I do not really want to have to have another Omeka Item of class E12 Production just to be able to attach properties for who produced the item, where it was produced, and at what time period it was produced. I would prefer to be able to attach a “place of production” direct to the object, and a creator (or creators), potentially with roles. But CIDOC-CRM would expect an object of class E39 Actor to be linked to the E12 Production via property P14 “carried out by” to signify that the production of the object was carried out by a certain person.

So theoretically that is all very good, but what makes sense for using Omeka?

As it happens, I am not wanting to build these items in Omeka manually, as we have the data in another system and will be synchronising it across into Omeka via the API. So there’s no particular problem in creating an item of class Production to be linked to each object (though it might be tricky making a single Production object to link to several objects which were produced together).

My main problem comes with what the search and display interface would then be like for the user. I don’t want them to be retrieving in results a load of Production class items. I want them to retrieve the actual museum objects, and for the display of a museum object to include all the details of the production as part of the web page.

Is there any way to achieve that while staying with the CIDOC-CRM vocabulary and not departing from the standard?

I did wonder about value annotation. Suppose you have the object as an Omeka Item of class E22 Human-Made Object, then you could add a property P14 “carried out by” and thereby link to an Actor. (Property P14 is meant to have a domain of E7 Activity, so should not really be attached to a Human-Made Object.) But then you could use the value annotation and somehow indicate that the context of the “carried out by” was the Production of the object. I’m not happy with this approach because of the clash of domain, and it still would not display in a natural way without some more programming.

Another thing I wondered is whether the Production of the item would need to appear in Omeka a bit like the Mapping of an item or the Media, as a separate tab? But I do not know how you would achieve that: it would probably need a module writing.

Pointers to any people who are using CIDOC-CRM or another vocabulary for museum objects would be helpful!

4

Maybe have a look at Linked.Art, this is an application profile (“slimmed down version”) of CIDOC.

5

That is a helpful site, and easier to get to grips with, but as far as I can see there is still the problem of things like the Production of an object being in a separate class. Looking at the JSON-LD for an item using the Omeka-S API I can see that the fields one can add through the normal editing interface tend to look like this:

    "dcterms:title": [
        {
            "type": "literal",
            "property_id": 1,
            "property_label": "Title",
            "is_public": true,
            "@value": "coats (Embroidered and stitched green velvet coat)"
        }
    ],

That is for a single literal value. If it’s a repeated literal, it is similar. If we want, we can create concepts such as a material as an Omeka item. Then from the object end the JSON-LD would look like this (first is a literal, second is a linked resource):

    "cidoc:P45_consists_of": [
        {
            "type": "literal",
            "property_id": 451,
            "property_label": "consists of",
            "is_public": true,
            "@value": "copper alloy"
        },
        {
            "type": "resource",
            "property_id": 451,
            "property_label": "consists of",
            "is_public": true,
            "@id": "https://caxton-test.durham.ac.uk/omeka-s/api/items/16095",
            "value_resource_id": 16095,
            "value_resource_name": "items",
            "url": null,
            "display_title": "Bronze"
        }
    ],

But that is quite a simple example, where the linked concept is describable by the single term “Bronze”. If you look at the structure for the Production of an item on the linked.art website we see that the basic object has a “produced_by” property but that includes things like the timespan of the production event, where it took place, and who carried it out:

{
  "@context": "https://linked.art/ns/v1/linked-art.json",
  "id": "https://linked.art/example/object/nightwatch/5",
  "type": "HumanMadeObject",
  "_label": "Night Watch by Rembrandt",
  "produced_by": {
    "type": "Production",
    "timespan": {
      "type": "TimeSpan",
      "_label": "1642",
      "begin_of_the_begin": "1642-01-01T00:00:00Z",
      "end_of_the_end": "1642-12-31T23:59:59Z"
    },
    "took_place_at": [
      {
        "id": "https://linked.art/example/place/amsterdam",
        "type": "Place",
        "_label": "Amsterdam"
      }
    ],
    "carried_out_by": [
      {
        "id": "https://linked.art/example/person/rembrandt",
        "type": "Person",
        "_label": "Rembrandt"
      }
    ]
  }
}

Clearly in Omeka I could create an item which is of class Production and attach the time, place and actor there, and then link from my object to the Production resource. But then by default none of the production information would appear in the JSON-LD for the object as retrieved in the API and non of the production information would appear to the user when viewing the object in Omeka. There would be a link to the Production resource, but what user would find it convenient to follow such a link just to find out that the item was made in Amsterdam by Rembrandt?

We have, however, experimented with the mapping module, and I see that in the JSON-LD for a point associated with an item, we have a more complex structure than for the ordinary literals and resource links:

"o-module-mapping:mapping": {
        "@context": "https://caxton-test.durham.ac.uk/omeka-s/api-context",
        "@id": "https://caxton-test.durham.ac.uk/omeka-s/api/mappings/3348",
        "@type": "o-module-mapping:Map",
        "o:id": 3348,
        "o:item": {
            "@id": "https://caxton-test.durham.ac.uk/omeka-s/api/items/16026",
            "o:id": 16026
        },
        "o-module-mapping:bounds": "65 ,25 ,75 ,35"
    },
    "o-module-mapping:feature": [
        {
            "@context": "https://caxton-test.durham.ac.uk/omeka-s/api-context",
            "@id": "https://caxton-test.durham.ac.uk/omeka-s/api/mapping_features/4641",
            "@type": "o-module-mapping:Feature",
            "o:id": 4641,
            "o:item": {
                "@id": "https://caxton-test.durham.ac.uk/omeka-s/api/items/16026",
                "o:id": 16026
            },
            "o:media": null,
            "o:label": null,
            "o-module-mapping:geography-type": "Point",
            "o-module-mapping:geography-coordinates": [
                53,
                32
            ]
        },
        {
            "@context": "https://caxton-test.durham.ac.uk/omeka-s/api-context",
            "@id": "https://caxton-test.durham.ac.uk/omeka-s/api/mapping_features/4642",
            "@type": "o-module-mapping:Feature",
            "o:id": 4642,
            "o:item": {
                "@id": "https://caxton-test.durham.ac.uk/omeka-s/api/items/16026",
                "o:id": 16026
            },
            "o:media": null,
            "o:label": null,
            "o-module-mapping:geography-type": "Point",
            "o-module-mapping:geography-coordinates": [
                70,
                30
            ]
        }
    ]

This shows that via a module you can add more complex structured data to an object. I suppose this means that it would be possible to write something so that the CIDOC (or linked.art) Production class can be attached directly to the main object, with the module responsible for providing editing facilities for the Production attributes, including being able to add a Timespan which is itself subsidiary to the Production object. The module would also need to provide code for rendering them on the end-user interface.

If Omeka S were able to do that in a more general manner, attaching appropriate subsidiary nested classes as part of the main item, that would be a much more natural approach for use cases like ours. Would that be possible, and has anyone else developed anything like this?

6

Pulling out data from a linked resource and showing it directly on the “parent’s” page, that’s definitely something a module can do. Probably using the resource page blocks feature. I think something reasonably generic could be made as a module to do that: choose a property to “drill down” to the next level of, and choose the properties of that sub-resource that you want to present on the main resource’s page.

A custom theme could do much the same, and could be more tailored to a specific setup, but wouldn’t really be amenable to being a generalized solution.

On the API side modules, as you’ve seen, are free to add in more or less whatever they want to the JSON output, but also having an API client having to follow a link isn’t necessarily as onerous as it might be for a human site visitor.

1 Like
7

Thanks for the pointer to resource page blocks.

Another consideration is what would happen if the people involved in creating the objects are represented as items in Omeka S. Taking the CIDOC-CRM example, if we created Omeka items of class E39 Actor, and linked the E12 Production items to them. If a user then visited the page for a particular craftsman or sculptor, the default behaviour of Omeka would be to list as linked resources all the items with property P14 “carried out by” that person. But those items would be Production resources, not the actual objects that the sculptor had made.

Therefore having the Production information (place, time, actors) stored as separate items in Omeka would cause difficulties both for the rendering of the physical objects we want to describe, and for the rendering of the pages about the people involved, and, indeed, the places, if we want to create them as resources too.

I was thinking that this was an argument for storing the Production information entirely within the items of class E22 Human-Made Object, using a module to render the display properly, and to somehow index it correctly for searching. We would need to adapt the “Linked resources” rendering to link from items of class E39 Actor to the objects they had produced, and from items of class E53 Place to the objects made in that place.

But now I see that having a separate item of class E12 Production to carry the time/place/people information would have the advantage that we could also link from the Place to any Actor who had produced work at that place. Storing the Production information as part of the Human-Made Object somehow would allow linking between the Human-Made Object and the Place, and the Object and the Actor, but would not really facilitate a link from the Place to the Actor or vice versa.

Nevertheless, we do not really want the Production objects appearing as items that users can find or access in the Omeka interface. We would always want to sort of “pass through” that object to link to or fetch data from the related concepts. So on the page of a Place item, I would want to see in the “Linked resources” section a list of items of class Human-Made Object where the associated production event (P108i “was produced by”) has property P7 “took place at” the Place in question, allowing the user to review all the objects made at that place.

There would need to be a distinct list of items, also of class Human-Made Object where the object has property P62 “depicts” linking to the Place, allowing the user to see all the paintings and so on which depict this place.

I would also be interested to see a list of items of class Actor with property P14i “performed” linking to a Production event with property P7 “took place at” the current Place.

I wonder whether what I need to do is to store the Production information as a linked item in its own right, but somehow flag it to say that these items are not to be displayed as separate items to the end-user? Then we might devise a module to modify the behaviour of the links to related resources, so that when viewing the Human-Made Object, instead of showing a link to a Production event, the interface shows a rendering of that Production information, with the date or period of the event, the person who produced the object, and the place of production. The person and place would be links to the appropriate resources. The time period might be (e.g. “Ming dynasty”) or might not be, if it’s better handled as a literal, e.g. if the date is known pretty exactly.

And when viewing the Actor or the Place, the Linked Resources would be modified by the module so that, knowing that each has Production events linked, it would pass through those resources and instead show the user lists of the objects made by the Actor, or the objects made at the Place, and indeed, the actors who were working at that Place, and the places where the Actor carried out their work.

I can see that this could be quite generalisable to other complex models where there are many concepts which have classes, but where not all of those classes would be desirable as “first class citizens” in the actual end-user interface.

Another good example from CIDOC-CRM is the handling of things like dimensions of objects. For the end user, they just want to know the height, width, weight etc. of the object. In the CIDOC model we can have an E16 Measurement class (ultimately a subclass of E5 Event) and this associates via property P40 “observed dimension” an item of class E54 Dimension. That allows you to record who measured something. There is fortunately a shortcut from the domain E70 Thing to E54 dimension via the property P43 “has dimension” if you don’t want thet complexity, but even so we still would not want all of these things shown as actual items to the end user in the Omeka S interface.

The same arrangement exists in the linked.art model.

8

P.S. I would still be very interested to see any Omeka S sites out there that are using CIDOC-CRM or linked.art for museum objects (or any other standard vocabulary). @SharonLeon – you mentioned a lot of museum people are using it. I could probably learn a lot just from seeing what people have already achieved on live Omeka-S sites, which would save me from boring you all with my hypothesising!