Knora should tell the GUI which field can be editable for the ontology editor

[flavens]

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.

[benjamingeer]

Sorry, I think I probably don't understand the question.

All classes and properties in project-specific ontologies (the IRI doesn't contain api.knora.org) are editable. All classes and properties in built-in ontologies (the IRI contains api.knora.org) are not editable.

Could you give examples of classes and properties that you're not sure about?

[benjamingeer]

Also, are you aware of the work @tobiasschweizer is doing on parsing ontologies?

[flavens]

Sorry, I think I probably don't understand the question.

All classes and properties in project-specific ontologies (the IRI doesn't contain api.knora.org) are editable. All classes and properties in built-in ontologies (the IRI contains api.knora.org) are not editable.

Could you give examples of classes and properties that you're not sure about?

thank you for clarifying this point, it is clear for me now
maybe @kilchenmann has specific examples that do not fit here...

[flavens]

Also, are you aware of the work @tobiasschweizer is doing on parsing ontologies?

We will talk about it with Tobias next week!

[kilchenmann]

maybe @kilchenmann has specific examples that do not fit here...

No I don't have a special case.

[kilchenmann]

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?
In case we can edit more than renaming property label, the GUI should know, if the user can change those parameters. Otherwise we can disable the corresponding form elements.

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.

[benjamingeer]

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 knora-api:subjectType or knora-api:objectType, this doesn't keep you from changing the class's cardinalities.

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 knora-base:isLocked to project-specific classes and property definitions? (We already have something else called knora-api:isEditable, which indicates whether a property's values are editable.)

[benjamingeer]

we can't change the gui element resp. the property class anymore or change the cardinality. Probably this is anyway not provided by Knora?

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.

[benjamingeer]

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.

[kilchenmann]

Thank you Ben. Sounds good.

how about if I add a boolean predicate like knora-base:isLocked to project-specific classes and property definitions?

That would be nice.

we can't change the gui element resp. the property class anymore or change the cardinality. Probably this is anyway not provided by Knora?

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.

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...

[kilchenmann]

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.

Yeah, I know. That was my consideration, too.

[benjamingeer]

OK, I'll add an API operation to change the GUI element, and I'll add isLocked.

[benjamingeer]

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.