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
The need for application profiles can be challenged. Another option could just to rely on OWL and introducing new subclasses when there is a new need. However there are problems with this approach, they should be described.
Feature suggestion description
Describe the problem with subclassing in a distributed environment that also relies on the open world assumption.
Why does not OWL sovle this.
Alternative solutions (Optional)
No response
Additional information (Optional)
No response
The text was updated successfully, but these errors were encountered:
I was looking at the https://github.com/diggsweden/interoperable-specifications/blob/main/docs/background.md#the-cost-of-subclassing section after the call to action to see if it could be improved. It feels a bit like it doesn't belong in the background section. Since it's a bit opinionated regarding how to write interoperable specifications, perhaps it could be extracted into a style guide-type document? That could go a bit deeper into why sub-classes man not be optimal and how to handle various common designs.
Contact Details (Optional)
No response
What benefits does the suggestion solve?
The need for application profiles can be challenged. Another option could just to rely on OWL and introducing new subclasses when there is a new need. However there are problems with this approach, they should be described.
Feature suggestion description
Describe the problem with subclassing in a distributed environment that also relies on the open world assumption.
Why does not OWL sovle this.
Alternative solutions (Optional)
No response
Additional information (Optional)
No response
The text was updated successfully, but these errors were encountered: