Currently, when importing a ConceptSchema it will create automatically for every concept a skos:notation. This is not always wanted as the created notations are derived from the prefLabel and therefore more or less duplicates. Whereas a notation system should carry additional information. Anyway, we can either have a checkbox for import to allow overriding the atuomatic creation of notations and/or like with the legacy-ids have a button "Remove skos:notations" (and I guess I prefer at least the second option as we already have vocabularies imported, where we like to get rid of the automatic created notations).

Hi,
Thank you for the quick response on my last issue!
I am trying to batch-create concepts in python from a .csv file into an existing ConceptScheme using the API. As an authenticated admin user, I can GET data through the API but I am unable to POST anything due to an internal server error 500.

The error stack seems to point to the django function get_identity(identity), which is called in vocabs->models.py when setting permissions.
I would be very grateful if you can point me to a solution/workaround as the manual creation of the concepts is not a feasible option.
Thank you!

500
Undocumented
Error: Internal Server Error
Response body

NotUserNorGroup at /api/skosconcepts/
User/AnonymousUser or Group instance is required (got None)

Request Method: POST
Request URL: http://localhost:8000/api/skosconcepts/
Django Version: 3.1.5
Python Executable: /Users/user/opt/anaconda3/bin/python
Python Version: 3.7.9
Python Path: ['/Users/user/Desktop/vocabseditor-master', '/usr/bin/python3', '/Users/user/Desktop/vocabseditor-master', '/Users/user/opt/anaconda3/lib/python37.zip', '/Users/user/opt/anaconda3/lib/python3.7', '/Users/user/opt/anaconda3/lib/python3.7/lib-dynload', '/Users/user/.local/lib/python3.7/site-packages', '/Users/user/opt/anaconda3/lib/python3.7/site-packages']
Server time: Sat, 02 Oct 2021 10:39:01 +0000
Installed Applications:
['dal',
 'dal_select2',
 'django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.messages',
 'django.contrib.staticfiles',
 'reversion',
 'guardian',
 'crispy_forms',
 'django_filters',
 'django_tables2',
 'rest_framework',
 'webpage',
 'browsing',
 'vocabs',
 'mptt',
 'drf_yasg',
 'django_extensions']
Installed Middleware:
['django.middleware.security.SecurityMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'django.middleware.clickjacking.XFrameOptionsMiddleware',
 'reversion.middleware.RevisionMiddleware']


Traceback (most recent call last):
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/django/core/handlers/exception.py", line 47, in inner
    response = get_response(request)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/django/core/handlers/base.py", line 181, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
    return view_func(*args, **kwargs)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/rest_framework/viewsets.py", line 125, in view
    return self.dispatch(request, *args, **kwargs)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/rest_framework/views.py", line 509, in dispatch
    response = self.handle_exception(exc)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/rest_framework/views.py", line 469, in handle_exception
    self.raise_uncaught_exception(exc)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/rest_framework/views.py", line 480, in raise_uncaught_exception
    raise exc
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/rest_framework/views.py", line 506, in dispatch
    response = handler(request, *args, **kwargs)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/rest_framework/mixins.py", line 19, in create
    self.perform_create(serializer)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/rest_framework/mixins.py", line 24, in perform_create
    serializer.save()
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/rest_framework/serializers.py", line 205, in save
    self.instance = self.create(validated_data)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/rest_framework/serializers.py", line 939, in create
    instance = ModelClass._default_manager.create(**validated_data)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/django/db/models/manager.py", line 85, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/django/db/models/query.py", line 447, in create
    obj.save(force_insert=True, using=self.db)
  File "/Users/user/Desktop/vocabseditor-master/vocabs/models.py", line 623, in save
    super(SkosConcept, self).save(*args, **kwargs)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/mptt/models.py", line 1014, in save
    super(MPTTModel, self).save(*args, **kwargs)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/django/db/models/base.py", line 754, in save
    force_update=force_update, update_fields=update_fields)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/django/db/models/base.py", line 803, in save_base
    update_fields=update_fields, raw=raw, using=using,
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/django/dispatch/dispatcher.py", line 179, in send
    for receiver in self._live_receivers(sender)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/django/dispatch/dispatcher.py", line 179, in <listcomp>
    for receiver in self._live_receivers(sender)
  File "/Users/user/Desktop/vocabseditor-master/vocabs/models.py", line 810, in create_perms_concept_created_by
    assign_perm('delete_skosconcept', instance.created_by, instance)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/guardian/shortcuts.py", line 86, in assign_perm
    user, group = get_identity(user_or_group)
  File "/Users/user/opt/anaconda3/lib/python3.7/site-packages/guardian/utils.py", line 91, in get_identity
    "(got %s)" % identity)

Exception Type: NotUserNorGroup at /api/skosconcepts/
Exception Value: User/AnonymousUser or Group instance is required (got None)
Request information:
USER: admin

GET: No GET data

POST: No POST data

FILES: No FILES data

• celery
• rabbit mq
• integrate new export function
• add some reporting view

Currently, the automatic created concept URIs without a legacy-id are built up using a #-character as separator: {base-uri}#concept{id}. This leads to problems with webserver redirect rules, as # is used for an anchor and therefore redirect rules are ignoring the # and all stuff behind it. Besides, it could also lead to problems, if on the resolving side anchors are used, because it will not allow it anymore (something like {base-uri}#concept{id}#{anchor-id} will break and not jump to the anchor).

It seems to be better to change the behviour of creating the automatic concept URIs and don't use the # anymore. Instead I propose to replace it with / and I also think that is is better readable if it also separates the concept. The schema would then look like {base-uri}/concept/{id}.

If changing to this new schema we need to be aware, that ConceptSchemes using the old schema shouldn't change to the new schema. One solution would be to use for such old vocabularies the legacy-id-field and add there the uri based on the old schema. This means that before switching to the new schema, all concepts that do not have a legacy-id-field should get a legacy-id with the old schema. Does this sound feasible or is there another option possible (maybe the date of creation defines the schema in use or maybe a configuration field to chose if it should use the old/new schema?).

Currently, the identifier of the conceptScheme also acts as base-URI for concepts without legacy id. If you do an export of a conceptScheme it will generate concept-URIs based on the identifier of the conceptScheme and additional the /concept[id] appendix. This is problematic, as the identifier of the conceptScheme must not be the base-URI. There are different approaches in place and they currently do have a direct unwanted effect on the concept-URIs. Sometimes, the conceptScheme has a dedicated URI, e.g. https://example.com/vocabulary/Scheme or it has a trailing slash at the end, e.g. https://example.com/vocabulary/. In the current setup this leads to concepts that in the first case have a uri https://example.com/vocabulary/Scheme/concept1234 and in the second case a URI https://example.com/vocabulary//concept1234 (two slashes in-between). Both is not expected, instead we like to be able to have a base-URI and additionally the possibility of a dedicated different conceptScheme-URI.

The current workaround is to have the identifier of the conceptScheme as baseURI without a trailing slash, e.g. https://example.com/vocabulary and use the legacyId field of the conceptScheme for the identifier of the conceptScheme, e.g. https://example.com/vocabulary/ or https://example.com/vocabulary/Scheme. That is not optimal and you need to be aware about this workaround. Could we think about a different approach, that makes it more clear to users, like a a dedicated field baseURI in the conceptScheme definition, that acts for the generation of all other URIs and an identifier-appendix field for the conceptScheme itself? @csae8092 what is your opinion on this and how is this complicating things?

this is needed to ingest vocabularies into skosmos

currently each push against master branch triggers test, publish and deploy workflow split this into

• test workflow (runs on each push no matter which branch)
• publish/deploy - runs on each new release

Hi,

I installed VocabsEditor locally (a great tool indeed) and I tried importing the entire GEMET Concepts SKOS vocabulary version 4.2.3. There are many skos:prefLabels with language values such as: "en-US" e.g.:

<skos:prefLabel xml:lang="en-US">SOCIAL ASPECTS, ENVIRONMENTAL POLICY MEASURES</skos:prefLabel>

and that was when I got the error from the job_status page:

{"exc_type": "DataError", "exc_message": ["value too long for type character varying(3)\n"], "exc_module": "django.db.utils"}

I modified models.py and for all CharFields with max_length=3 I changed it to max_length=10. Then I also modified forms.py, run makemigrations + migrate and importing worked just fine.

So, my suggestion would be that the maximum length of the language value could be longer. What the exact maximum value should be I can't tell precisely, but maybe this Best Practice RFC could be of help: https://www.rfc-editor.org/rfc/rfc5646 - hope it helps.

Cheers

Is there a way to get other concept URIs than <some schema URI>#concept<a number>?

It would be e.g. nice to have an URI based on skos:notation, separated with a slash instead of a hash like e.g. <some schema URI>/skos:notation

currently downloading a single concept filters the concept by prefLabel, which makes not much sense, especially because we do know the concepts PK anyways...

e.g. http://127.0.0.1:8000/vocabs/vocabs-download/?format=turtle&pref_label=29

When serializing a conceptScheme then for the titles a dc:title and an rdfs:label is created. Surprisingly, whereas different language titles are respected for dc:title, only one title is taken for rdfs:label. I can't see why this would make sense.

Example: you have a conceptScheme where in vocabseditor you defined a dc:title in English, e.g. "Example"@en and one in German, e.g. "Beispiel"@de. When serialising it will create additionally a rdfs:label (which is fine and should stay) but only with one of the titles for rdfs:label (I guess it takes the first that it finds in the database).

Looking in the code it seems that moving https://github.com/acdh-oeaw/vocabseditor/blob/master/vocabs/rdf_utils.py#L46 after https://github.com/acdh-oeaw/vocabseditor/blob/master/vocabs/rdf_utils.py#L49 should do the trick (and removing afterwards the lines 44-46). Could this work?

By definition the documentation properties (skos:note, skos:changeNote, skos:definition, skos:editorialNote, skos:example, skos:historyNote, skos:scopeNote) do not have a domain and range stated (see https://www.w3.org/TR/skos-reference/#notes - 7.5.1). Thus, they can also be used for a ConceptScheme and it may make sense for some of them, e.g. put general information about the vocabulary in skos:note. Currently, the ConceptScheme edit form does not have these documentation properties available, they are only available for Concepts. In my opinion, it would be good to add them also to the edit fom of ConceptScheme. Opinions?

Currently it is not possible to create dc:source without a language tag in Vocabs Editor. The following message appears: "Language is required when dc:source provided".
Because of this in Vocabs the dc:source is only shown when the language is also the one that is selected in the Vocabs. So if dc:source has @eng, and the selected language is English it will be shown, but if the selected language is German it will not appear. However, dc:source should always appear, but sometimes it is not possible to translate the dc:source (book title for example), so it can only be available in this one language.

If there is no language tag on the dc:source it would be possible that the dc:source would always be shown, no matter which language would be selected in the Vocabs.

Currently if I export a ConceptScheme that contains Collections without Concepts, such Collections will not show up in the dump (one example is our VICAV. It could be that skosify kicks them out. Just to be sure, is this a behavior built into vocabseditor or is it indeed skosify that does this clean-up?

tbd: If vocabseditor is ignoring such Collections, then I tend to put them into the export. If skosify is the reason, then we accept it.

currently all files located in "media" are pushed after export of a single file; I guess it is better to actually commit/push the exported file

inject secrets et all via env-variables

top concept form field is commented out

if data is none what should be the default; lets say false

If importing a vocabulary (ttl-format) into vocabseditor that holds concepts with skos:exactMatch-relations, these relations are ignored and do not show up in the vocabseditor after successful import.

I've attached a simple example import (needed to add .txt because .ttl is not accepted by GitHub), that demonstrates this problem and I've imported it on our vocabseditor-instance, see the concept-view.

Expected fix: semantic relationships like skos:exactMatch should be respected in import (it is possible to add them in the edit view and to export them, so it seems that something goes wrong in the import queue - I didn't checked it other semantic relationships are also concerned).

Test vocabulary:
testit_exact.ttl.txt

something like
$ python manage.py dl_scheme --scheme-id=123

maybe some flag to indicate if existing file should be overridden or not

running with

• Django==3.1.5
• djangorestframework==3.12.2

fails due to

vocabseditor/vocabs/api_views.py", line 20, in SkosConceptSchemeViewSet
filter_backends = (filters.DjangoObjectPermissionsFilter, )
AttributeError: module 'rest_framework.filters' has no attribute 'DjangoObjectPermissionsFilter'

TypeError at /vocabs/concepts/update/16094

'tuple' object is not callable

notebook-requirements are not really needed for running the application, get rid of them

As the list of vocabularies in the vocabseditor is growing, it could be useful to only show users the vocabularies that they can edit, based on their permission. This is clearly a feature request, but it could be useful in the long term. I would still allow to see all other vocabularies, but this could be a dedicated option in the ConceptScheme-overview.

Proposal: By default, show only the ones where a user has created or is curating a vocabulary. Introduce a dedicated option to show all ConceptSchemes available in vocabseditor.

@csae8092 What is your opinion on this?

Hello,

I try to run the application with docker, I followed the instructions and executed on my side. I would like to check the docker compose file but couldn't find it. Can you help me with that?

check which settings need/should be replaced by env-variables

Hello,
Congratulations on a great tool!

Unfortunately, it's not possible to add relations from Dbpedia and adding the URL does not work either in the different relation fields (skos:related, ...)

Hi, Not sure if this is the right forum to ask questions, but I am trying to use docker image with Docker desktop under Win 10 environment with localhost:8020 . Docker container for Vocabseditor running fine. However, it does not show me any webpage. It says "The page isn't working right now. localhost didn't send any data". Is there any suggestion or help I can get in this regard? Thank you in advance.

The main README does not mention the registry. And when trying to pull and run the latest image I get the following error:

vocabs-editor         | Traceback (most recent call last):
vocabs-editor         |   File "manage.py", line 22, in <module>
vocabs-editor         |     execute_from_command_line(sys.argv)
vocabs-editor         |   File "/usr/local/lib/python3.8/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line
vocabs-editor         |     utility.execute()
vocabs-editor         |   File "/usr/local/lib/python3.8/site-packages/django/core/management/__init__.py", line 420, in execute
vocabs-editor         |     django.setup()
vocabs-editor         |   File "/usr/local/lib/python3.8/site-packages/django/__init__.py", line 24, in setup
vocabs-editor         |     apps.populate(settings.INSTALLED_APPS)
vocabs-editor         |   File "/usr/local/lib/python3.8/site-packages/django/apps/registry.py", line 91, in populate
vocabs-editor         |     app_config = AppConfig.create(entry)
vocabs-editor         |   File "/usr/local/lib/python3.8/site-packages/django/apps/config.py", line 228, in create
vocabs-editor         |     import_module(entry)
vocabs-editor         |   File "/usr/local/lib/python3.8/importlib/__init__.py", line 127, in import_module
vocabs-editor         |     return _bootstrap._gcd_import(name[level:], package, level)
vocabs-editor         |   File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
vocabs-editor         |   File "<frozen importlib._bootstrap>", line 991, in _find_and_load
vocabs-editor         |   File "<frozen importlib._bootstrap>", line 973, in _find_and_load_unlocked
vocabs-editor         | ModuleNotFoundError: No module named 'django_extensions'

Currently, the legacy-id field in conceptScheme is ignored. It does not have an effect on the created URL for the conceptScheme. The only field that is respected is the identifier-field. Here we run into the problem described in #58.

Depending on the solution for #58 we either need legacy-id as a possibility to generate a custom conceptScheme URI or we find another solution which then may result in removing the legacy-id-field from the conceptScheme edit form.

I tend to use the identifier of conceptScheme as baseURI and to have a dedicated field to extend this baseURI with custom values, e.g. adding /Scheme. Generally spoken, we run here into many issues if we like to check plausibility of the generated URLs. I'm currently fine without checks, but we need to think about some rules how this can be better controlled, e.g. avoiding URLs having //.

and set up gh-workflow to check linting

Dear developers,

Thank you for such useful software. I have a concept scheme which has around 1120 concepts, while I try to download this concept scheme as RDF/XML or Turtle it gives me error. At the begining there wasn't such error, however I think with the increased number of concepts the system cannot download the concepts. Any suggestions in this point? Thank you!

add some button to concept scheme detail view visible only for authorized users allowing to bulk delete legacy_id values of related concepts