Questions & Answers

Welcome to the MORe Questions & Answers section. Here you can find the most asked questions and their answers.

Metadata Sources

MINT

You should use MINT in the cases where the native metadata schema is not one of the intermediate schemas, and therefore transformation to one of those is required.


LoCloud Collections

Whenever you want to upload your data from scratch. For instance an excel file.

Extended Question:

Here is an OAI test for iconographic archives. Should we use Mint or More or both?

Find the records here

Answer:

MORe supports the ingestion of a dataset through an OAI endpoint. However, the used schemas in MORe are: EDM, ESE, OAI_DC, CARARE and OMEKA-XML. If another schema (e.g. mods or mets) is used, then MINT should be used so as to transform the dataset to one of the above schemas. This means that if you have a dataset in omeka-xml or oai_dc, you could immediately use MORe to harvest it.

Extended Question:

LoCloud Collections seem to only be ingested within MINT from an OAI endpoint (thanks to the OAI-PMH repository plugin embedded in Omeka). As MORE insure this same OAI ingesting functionality , can't we just bypass MINT with this kind of already quite well structured dataset? I guess MINT would be useful while working on more intricate data structure, and based on an Omeka-XML export from LoCloud Collections ?

Answer:

MORe supports the ingestion of a dataset through an OAI endpoint. However, the used schemas in MORe are: EDM, ESE, OAI_DC, CARARE and OMEKA-XML. If another schema (e.g. mods or mets) is used, then MINT should be used so as to transform the dataset to one of the above schemas. This means that if you have a dataset in omeka-xml or oai_dc, you could immediately use MORe to harvest it.

Here are some points about the identifiers used in EDM schema:

  • the rdf:about of edm:providedCHO and rdf:resource of edm:aggregatedCHO should have the same value
  • the rdf:about of ore:Aggregation should have different value, defining a unique identifier (not just a number)
  • the rdf:about of edm:WebResource should have the same value of rdf:resource either of edm:isShownAt or edm:isShownBy

In oder to create unique identifiers for ore:Aggregation, you could use the same url of edm:providedCHO or edm:aggregatedCHO, adding an extension like #aggregation to the identifer. For example, if you use the value "http://more.locloud.eu/object/DCU/1" on edm:providedCHO or edm:aggregatedCHO, you could use the value "http://more.locloud.eu/object/DCU/1#aggregation" on ore:Aggregation.

Publishing Workflow

Actually yes. After the harvest, you should continue with the ingestion of the content (Please note that this will not be done automatically. Instead, you should manually start it.). Once the ingestion is completed, you can trigger one of the following jobs namely transformation, enrichment, and publication but always with respect on your case. You can find more information in the How To section and User Documentation section.
You should transform your package whenever your metadata schema is different than the target schema. In our case the target metadata schema is EDM as our main goal is the publication to Europeana. Therefore, if your schema is not EDM you should proceed to the transformation of your package.
Firstly you are kindly requested to check if there are any data to be enriched. To be more specific, your records must have the necessary information:
  • spatial (placeName or coordinates)
  • thematic (subject)
  • temporal (date)
Otherwise you will not be able to use the respective enrichment services. For example, you cannot use services which enrich the spatial information if you do not have in advance any spatial information.

Having that checked, you can continue to the enrichment of your data. With respect to the type of information that you want to enrich, select the appropriate enrichment services.

Spatial
  • Geo Normalization
  • GeoLocation
  • Geonames Geocoding
  • GeoInvertion
Thematic
  • Vocabulary
  • Vocabulary Matching
  • Background Link
Temporal
  • Perio.do

Moreover, you should take into account the format of the information in your records in order to choose the right services (find out more in the How To section). For instance, in the following case we need Geo Normalization in order to identify and split the coordinates.

<edm:Place>
<skos:prefLabel>34.916515, 33.014361</skos:prefLabel>
</edm:Place>

In contrast, we do not need Geo Normalization in the following case.

<edm:Place>
<wgs84_pos:lat>34.916515</wgs84_pos:lat>
<wgs84_pos:long>33.014361</wgs84_pos:long>
</edm:Place>

Finally, the enrichment services that you will choose must be orchestrated in an enrichment plan. Please always remember that the execution order of the services is essential.

Unfortunately no. However, you will be informed through the team of MORe Aggregator.