Omeka S export with specific vocabulary for coverage and subject - interaction with ValueSuggest in Omeka S

Plugins
1

Hello,

Here we have 1900+ archeological photos from a retired researcher we want to describe in Tropy before importing them to a brand new Omeka S that is not yet configured (we intend to use the ValueSuggest module that provides the PACTOLS vocabulary as Data Type).

In Tropy we intended to use the PACTOLS vocabularies in dcterms:spatial, dcterms:temporal and dcterms:subject.

If we put the PACTOLS term’s handle (or the ark) uri as value in Tropy and if the template in Omeka S is configured with PACTOLS as Data Type for the dcterms fields above, will ValueSuggest complete with the pactols label ?
Or do we need to use the Pactols labels as values in Tropy for ValueSuggest to get the URIs in Omeka S ?

We need advices before beginning this hard work (that will be a lot easier thanks to the tools you provide :slight_smile: )

2

I copied this message here in the Omeka S forum because I don’t know where it is most relevant…

3

There’s not yet a good counterpart to Omeka’s ValueSuggest in Tropy. If you enter the actual value URIs in Tropy (the built-in suggest tool might be helpful if most values occur repeatedly) then we should definitely be able to ensure that the values arrive in a way that Omeka S associates them with the right vocabulary / ValueSuggest widget.

I would suggest you try out a simple dry-run with a single item; Tropy’s Omeka S plugin essentially sends JSON-LD over the wire. By default the value URIs will probably be send as JSON-LD @value and Omeka S may, correctly, expect them to be sent as @id instead – we may have to adjust the plugin a little bit to make sure this works.

@jimsafley is there anything besides setting the correct value and datatype we need to consider when sending ValueSelect compatible data?

4

The resource template is irrelevant here because it only dictates how values are added from within the Omeka S interface, not from without.

For Omeka S to recognize a PACTOLS data type, the ValueSuggest module must be installed and the payload must set the value object’s type to “valuesuggest:pactols:all” or “valuesuggest:pactols:sujets”. For example:

    "dcterms:subject": [
        {
            "type": "valuesuggest:pactols:all",
            "property_id": 3,
            "@id": "https:\/\/ark.frantiq.fr\/ark:\/26678\/pcrt0ekV2PGhfe",
            "o:label": "r\u00e9miniscence"
        }
    ]

In this case Tropy would need to provide some way to customize the type for specific values. Alternatively, Tropy could just send a value object using the native “uri” type, and Omeka S would store and render the value as a URL (given the @id), which is sufficient for most applications.

5

@jimsafley thanks!

@ujubib I think setting the valuesuggest type would call for a customized version of the Omeka plugin: it would be a simple change to make this work for your specific data, but hard to think of an easy way to make this configurable in a general way. I can help you set this up if the alternative of displaying links is not acceptable.

6

@inukshuk @jimsafley a lot of thanks for your replies :slight_smile:

As I said, our Omeka S is not configured yet and we are just beginning the work in Tropy.
Thanks to you we now know it’s better to put the URIs as value in Tropy.
When it’s time, I will look the code of the plugin to try to customize it. If I can’t, I will come back here for asking help.
This will be our first linked data project and thanks to you and the great tools you make, it will be easier to achieve :slight_smile:

1 Like