You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a HermeneutiX user I want to be able to define the same semantic relations/roles in multiple languages, in order to be able to export the same analysis for varying target languages/contexts.
One option would be to have multiple sets of relation models and allow switching between them.
Another option could be to split out the configuration of semantical roles from the relation setup and cater for multiple sets/profiles of translations for those roles.
This is based on the suggestion from Phil (@j2l) for Issue #14.
The text was updated successfully, but these errors were encountered:
For this, the overall configuration of relations needs to be simplified/cleaned up, before adding even more complexity with those alternative languages (however that's supposed to be handled).
I'm open for design suggestions.
The overall approach should pretty much follow what is being done for #14 (syntactic functions). But since the semantic relations are currently not part of the file structure and only dependent on whatever is configured in the respective instance of SciToS/HermeneutiX, some adjustments will be required. I.e. probably need to rely on the relations defined in an opened file and only apply the configured semantic relations on new projects (as for the syntactic functions) instead of always offering the configured relation options.
As a HermeneutiX user I want to be able to define the same semantic relations/roles in multiple languages, in order to be able to export the same analysis for varying target languages/contexts.
One option would be to have multiple sets of relation models and allow switching between them.
Another option could be to split out the configuration of semantical roles from the relation setup and cater for multiple sets/profiles of translations for those roles.
This is based on the suggestion from Phil (@j2l) for Issue #14.
The text was updated successfully, but these errors were encountered: