Skip to first unread message

Roger Rutishauser

unread,
Apr 9, 2020, 6:32:41 PM4/9/20
to AtoM Users
Hi there

When importing SKOS, I was assuming that the URI in skos:Concept, e.g. 
will be the same as the URI of the term in AtoM. 

Instead, an auto-generated slug like "gkxb-c9rw-5hr5" is used, e.g. https://atom2004-test.docuteam.ch/index.php/gkxb-c9rw-5hr5/, and the URI of skos:Concept is stored as "source note(s)" (as discussed in the other forum post).
When browsing to that place/term in the GUI, I see the entry "Source note(s)" with the URI from skos:Concept as a clickable link. Clicking on it, results in "Sorry, page not found".

Questions:
- What can I do so that when importing terms, the slug of *my* SKOS Concept is used instead of random characters?
- If not possible - how can I get rid of the link? Because when I want to edit the term, the field is yellow and can't be changed/deleted. I don't want to have dead links shown to users, as you might understand.

Thanks!

Roger

Dan Gillean

unread,
Apr 13, 2020, 10:47:08 AM4/13/20
to ICA-AtoM Users
Hi Roger, 

For anyone else stumbling on this thread in the future, I'm going to drop a link to our previous thread about SKOS source notes: 
Though it's clear we need to do some review to consider the best import mappings, the purpose of capturing the rdf:about URL in the Source notes field is to preserve a link to the source system/vocabulary from which the terms originate. If you were importing something like Library of Congress Subject Heading terms, this would be useful for maintaining a link back to the original term. It looks a bit stranger when you are roundtripping terms in the same AtoM instance. 

Typically the term slug *should* be generated from authorized form of name of the term, so I'm not sure what's happening in your case - though given your second comment: 

Because when I want to edit the term, the field is yellow and can't be changed/deleted.

... I suspect that you might be working in a different user interface language than the default installation culture of your AtoM instance? Usually, when you see a term in a yellow box above a field in an edit page, this is part of AtoM's translation interface. It means that the original term was created in a different culture than the current user interface culture, and is showing you the original source term so that you can add a translation:

translate-terms.png

I would suggest exploring this a bit more and seeing if you can figure out the source culture that the term was created in. For example, see if there is a language drop-down on the term view page: 

terms-language-dropdown.png

You should be able to modify the original term when entering edit mode in the source culture user interface. Additionally, you should be able to click "Delete" in the button block at the bottom of the page to delete the term, if desired, regardless of culture (unless it is a locked term - but that shouldn't apply to a user-imported term). 

You can also check the default installation culture of your site in apps/qubit/config/settings.yml (see here). If you make changes: 
  • AtoM expects ISO 639-1 two letter language codes (e.g. en, fr, es, de, etc)
  • Make sure that you preserve the spacing as it is currently set in the configuration file 
  • Clear all caches, restart PHP-FPM, and re-index your site after making changes. 
If you have imported the terms in a different culture, you may want to make sure there is an English translation present for them - I believe that the slug generation should be based on the source term regardless of culture, but it's possible you've found a bug. I will try to investigate soon. In the meantime, we can try to regenerate all the slugs in your site, using the slug generation task with the --delete option.

One important side effect of this: it will delete ALL slugs in the site, and then regenerate them based on your settings. If you have customized some slugs manually using the rename module, those will be deleted and replaced as part of the following task. There's likely a way I can figure out how use SQL to delete just the term slugs before running the task, if that would help - let me know. Otherwise, we can try running the following from the root AtoM installation directory - typically /usr/share/nginx/atom if you have followed the recommended installation instructions: 

For good measure, I would clear the application cache and re-index again after. 

Let us know if that helps! 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
he / him


--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/e4a4e8d9-81af-4b07-871d-291aed3f3197%40googlegroups.com.

Roger Rutishauser

unread,
Apr 16, 2020, 8:15:44 AM4/16/20
to AtoM Users
Hi Dan

Yes, I understand what the reason is for having rdf:about URL in the notes field. Fine with me!

Although I actually intended to take make sure I have the correct language set, it seems like I didn't. Because after a new import, the slugs were created from the name field. 
Slugs look fine. All good! Thanks for your support.

Roger
To unsubscribe from this group and stop receiving emails from it, send an email to ica-ato...@googlegroups.com.

FARUQ Hāshimīyūn (Hamzi)

unread,
Dec 22, 2022, 1:35:35 AM12/22/22
to AtoM Users
Reply all
Reply to author
Forward
0 new messages