-
Notifications
You must be signed in to change notification settings - Fork 18
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
Knora should tell the GUI which field can be editable for the ontology editor #1405
Comments
Sorry, I think I probably don't understand the question. All classes and properties in project-specific ontologies (the IRI doesn't contain Could you give examples of classes and properties that you're not sure about? |
Also, are you aware of the work @tobiasschweizer is doing on parsing ontologies? |
thank you for clarifying this point, it is clear for me now |
We will talk about it with Tobias next week! |
No I don't have a special case. |
I think it was a misunderstanding here. The GUI should know, if a property as part of the project-specific ontology can be edited or not. We know that this is possible, as @benjamingeer confirmed, but only as long the property-class doesn't have a value yet. Yes, renaming a property shouldn't be a problem. But in a case of an existing value, we can't change the gui element resp. the property class anymore or change the cardinality. Probably this is anyway not provided by Knora? I can imagine that it could be complicated to get information if the project specific property class is editable or not (does it have a value?). But from a user perspective it's better when he see what is editable and what isn't. We don't know if it's possible. I think this was the main question. |
OK, now I understand. Currently the logic is very simple and strict: if a class or property is referred to anywhere (by something in an ontology or by something in data), you can't edit it, except to change its label or comment. The only exception is that if a property refers to a class via This kind of information is easy to query, and we could add more exceptions if needed. To make it possible to disable editing in the GUI, how about if I add a boolean predicate like |
Currently the only way to change a property's GUI element is to delete the property and create it again. But I could add an API operation for this. |
It wouldn't always be safe to change the cardinalities of a class that's already used in data, because if you added a required cardinality on a property, the existing instances of the class would be invalid because they wouldn't have that property. We could have more sophisticated logic to allow you to add only optional cardinalities, but I think Lukas felt that we should wait until we have a real use case for this. |
Thank you Ben. Sounds good.
That would be nice.
Yes, if it's possible to add an API operation, it would be simpler for us. We can solve it as well on the GUI side, but this would be a bit hackie... |
Yeah, I know. That was my consideration, too. |
OK, I'll add an API operation to change the GUI element, and I'll add |
Having thought about this some more: the problem is that the answer to whether an entity is used or not could change at any time. So I think it's better to leave the buttons enabled, and handle the error response if you get it. See how it goes, and we can reopen this later if there are new ideas. |
In the ontology editor, we would like to know from Knora which resource class and properties can be editable in order to disable input field in the edit form accordingly.
The text was updated successfully, but these errors were encountered: