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:
... 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:
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:
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
). If you make 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:
- php symfony propel:generate-slugs --delete
For good measure, I would clear the application cache and re-index again after.
Let us know if that helps!