-
Notifications
You must be signed in to change notification settings - Fork 2
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
language fall back problem #128
Comments
@zeginis - The Would you prefer the fallback behaviour to apply when querying? Or would you like a different fallback behaviour (.e.g just the matching language and any literals without a language)? |
@lkitching I thought that the language fallback worked also for querying, but it is ok. However the point 2 is a bug then.
|
@zeginis - If you don't specify a
would not match labels with an
should return the label. Would you prefer it if the default returned all labels if no |
I see so What do you mean with "all labels"? E.g. if there are |
@zeginis - Yes, the By "all labels" I meant we could return a list of all the labels for each dimension/measure, but thinking about it this might not be a great idea since we only expect a single label for each language and would require a change to the schema. We could apply the fallback behaviour in the case of no |
I agree that "all labels" is not a good option. Yes we could apply also the fall back at querying using the order you mention. |
Language fall back does work properly:
:schema-label-language en
and dataset label = no languageThe query return no results:
The SPARQL produced is:
:schema-label-language en
and measureProperty language = enThe query return no label for measures although there is a label with
@en
The result is:
The SPARQL created is:
The text was updated successfully, but these errors were encountered: