-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add support for multilingual RDF #124
base: master
Are you sure you want to change the base?
Conversation
Hi @stefina, Is this the final implementation or is something missing? It seems that the actual change in the pull request changes the type of the expected default value if no value is in the graph to the given predicate. I think therefore some of the unit tests are failing, because the return value is different. As @amercader mentioned in #55 there is a need to use ckanext-scheming for enabling proper storing of the multilingual fields in the database. A minimal example for the fields title and notes should be could be helpful to get started with it. |
@seitenbau-govdata I added some documentation to make it clear how this is used. Would be good to hear your opinion on it. |
@stefina It looks good to me. Maybe a hint would be helpful that the plugin ckanext-scheming is needed to store the values in several languages in the database properly. As I have understand the ckanext-scheming is required then, right? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stefina many thanks for this really powerful feature, and thanks @seitenbau-govdata for the feedback.
For the record, the extension that handles multilingual fields is ckanext-fluent (generally used alongside ckanext-scheming), so this should be mentioned in the docs.
IIUC, with this implementation people would need to create their own profiles, and in them for each field that needs to be extracted, call _object_value
with multilang=True
. Does it make sense to have a global flag (passed when creating the profile instance or controlled via config option) to enable multilingual support globally? Or perhaps is better to control which individuals fields are handled in this way?
I just don't know enough about the use case or how multilingual metadata is encoded in RDF (ie are all text fields generally translated, just a subset, etc) so your view on this are appreciated.
ckanext/dcat/profiles.py
Outdated
return '' | ||
|
||
def _add_multilang_value(self, subject, predicate, dataset_key, dataset_dict): # noqa |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was not initially clear what this function did, would you mind adding a short docstring along the lines of "this function will add a new triple for each language defined in a multilingual field dict, eg ..."
Actually I'm wondering if the logic in this function could be incorporated to the existing helpers to add triples directly, eg here so it is handled automatically on existing profiles without having to write your own and use _add_multilang_value()
@@ -80,6 +80,33 @@ def test_object_value_not_found(self): | |||
|
|||
eq_(value, '') | |||
|
|||
def test_object_value_multilang(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a small test for the other way around (ie from dict to graph)?
aa0a109
to
1920630
Compare
Make sure the original behaviour is kept, if no multilang is set to false.
433702e
to
ad1b589
Compare
ad1b589
to
e1418da
Compare
e1418da
to
eae7d82
Compare
No description provided.