Omeka S export: Class and Type

Noob here, so I hope I have this right.

It seems that the Omeka S exporter puts the Tropy Type into the Omeka S “type” field, but it seems that it’s the Omeka S “Class” field that’s for the dc types. See this forum entry over at Omeka.

If thats right, could the exporter at least provide an option on which field to stick those data in?

TIA.

@jimsafley what do you think?

We could add an option to the plugin to convert dcterms:type to rdf:type – would that change anything?

If I understand the situation with Omeka S correctly, the Class field is really the place for Tropy’s type data, so whatever solution results in that would be good. :slightly_smiling_face:

Ideally, the exporter should map Tropy’s type to Omeka’s resource class (its @type), but Omeka must already be aware of the class (the class’s vocabulary must be imported). The export logic could be:

  • If the class exists in Omeka, map Tropy type to Omeka class
  • Otherwise, map Tropy type to dcterms:type

Per that link I put in above:

An item’s Class [in Omeka S] is implicitly the item’s dcterms:type

Thanks @jimsafley!

We actually can’t edit an item’s type/class yet, so I was mostly wondering about the actual dcterms:type metadata field: those fields are currently send over to Omeka as dcterms:type (and by default we also map dc:type to dcterms:type). Would there be any benefit if we map dcterms:type to Omeka’s resource class (provided dcterms:type is set to a RDF class that Omeka knows about)?

Once Tropy’s type can be set via the UI we’ll definitely follow the approach you’ve outlined above; but until then, would it be better to map dcterms:type to the resource class? Personally, I feel like it would be better to stick to the current behavior, just sending dcterms:type over as dcterms:type, but the OP made me wonder if there would be some benefit from adding a way to map this to the resource class instead.

I agree that the default should be dcterms:type -> dcterms:type. I don’t see a downside to providing an option to map dcterms:type -> rdf:type, so long as it falls back on dcterms:type if the resource class doesn’t exist in Omeka.

I’d suggest that the benefit is that this is how Omeka S uses its Class (=resource class, I assume), namely, to hold dcterms:type, unless I’m misunderstanding something.