What am I doning wrong with Omeka S imports and ValueSuggest and Vocabularies?

What am I doing wrong when trying to import using valuesuggest?

I am running Omeka 2.0.2. I am trying to do the following:

Prepare a CSV listing out various archives, using linked data vocabularies (Getty, LCSH, Homosaurus), and then import that using CSV import and have it display correctly.

This looks like this currently:
dc:title https://www.americangenrefilm.com/ American Genre Film Archive
Mapping 30.26/ -97.74
dc:creator American Genre Film Archive
dctype: MovingImage;Collection;Image
skos:exactMatch United States;North America
dcterms:temporal Twentieth century - LC Linked Data Service: Authorities and Vocabularies | Library of Congress 20th_Century;Twenty-first century - LC Linked Data Service: Authorities and Vocabularies | Library of Congress 21st_Century
skos:related Homosaurus Vocabulary Site
dc:description Formed in 2009, the American Genre Film Archive (AGFA) is a 501(c)(3) non-profit located in Austin, Texas. AGFA exists to preserve the legacy of genre movies […]

The following terms work:
dc:title https://www.americangenrefilm.com/ American Genre Film Archive
Mapping 30.26/ -97.74
dc:creator American Genre Film Archive
dc:description Formed in 2009, the American Genre Film…

The following do not:
dctype: MovingImage;Collection;Image
skos:exactMatch United States;North America
dcterms:temporal Twentieth century - LC Linked Data Service: Authorities and Vocabularies | Library of Congress 20th_Century;Twenty-first century - LC Linked Data Service: Authorities and Vocabularies | Library of Congress 21st_Century
skos:related Homosaurus Vocabulary Site

I import like this

But it comes out like this, without clickable links for metadata, or in the Spatial coverage field

The “view source” of the page looks like this

[{“type”:“uri”,“property_id”:219,“property_label”:“has related match”,“is_public”:true,“@id”:“http://homosaurus.org/v2/crossdressers”,“o:label”:“Crossdressers”}]

It should probably look like this

[{“type”:“valuesuggest:homosaurus:homosaurus”,“property_id”:211,“property_label”:“has related”,“is_public”:true,“@id”:“http://homosaurus.org/v2/crossdressers”,“o:label”:“Crossdressers (Cross-dressers)”}],“skos:relatedMatch”:

I have even made a resource template like someone instructed and I import under that

Since the Value Suggest plugin just offers suggestions, it doesn’t interface with the CSV Import plugin, where there’s no UI for the user to choose from among and select the “right” suggestion.

Importing linked data with the importer requires using the URI data type for importing and provide the linked data URI (and optionally the desired label), which it seems like you’re doing here, partially: to my eye you selected to import only the Title, Temporal Coverage, and “has related match” fields as URIs, and those are the ones that are clickable in your screenshot.

1 Like

Thanks for the clarification. I understand what you’re saying re:valuesuggest and CSV plugins, and that I need to include the URI in the CSV import.

This is what I have in the CSV for 21st_Century

Twentieth century - LC Linked Data Service: Authorities and Vocabularies | Library of Congress 20th_Century;Twenty-first century - LC Linked Data Service: Authorities and Vocabularies | Library of Congress 21st_Century

the result is

{“type”:“uri”,“property_id”:41,“property_label”:“Temporal Coverage”,“is_public”:true,“@id”:“http://id.loc.gov/authorities/subjects/sh85139024.html”,“o:label”:“21st_Century”}]

so if I use (crossdressers) in this manner the result is

“skos:Match”:[{“type”:“uri”,“property_id”:219,“property_label”:“has related”,“is_public”:true,“@id”:“http://homosaurus.org/v2/crossdressers”,“o:label”:“Crossdressers”}],

Is that the same (from the computers/reasoners’ perspective as:

“skos:related”:[{“type”:“valuesuggest:homosaurus:homosaurus”,“property_id”:211,“property_label”:“has related”,“is_public”:true,“@id”:“http://homosaurus.org/v2/crossdressers”,“o:label”:“Crossdressers (Cross-dressers)”}],

If so, then it looks like I was doing it right and had no reason to be worried!

From a linked data perspective it’s just the URL itself that’s relevant, more or less, so those two are equivalent in that sense. I will note that one is skos:Match and one is skos:related, which obviously is different but that looks like just a simple situation of choosing the property you prefer there.

1 Like

yes! Am aware of the issue where I used SKOS related and SKOS match, just did it for demo purposes here.

I appreciate the clarification. I wanted to also have those links be clickable for users to browse, say, all the items on “women” for example. I think there’s a plugin called Metadata Browse that allows that, but I didn’t know if it would interfere with the URIs.

Currently, Metadata Browse works by adding an extra link saying “view all items with this value,” for this very reason: it won’t conflict with the regular linked data link.

1 Like

you just made my day 100x better and gave me a big smile! thanks so much!