Open uscholdm opened 1 year ago
Are they saying they will create the inverse property, or just use the inverse label in the UI? I don't like the idea in either case.
In the first case, I don't believe we should be giving advice such as "We follow best practice X, but in case you don't want to follow X, this is the way we recommend doing it?" That strikes me as an incoherent position. Best practices for breaking best practices??
In the second case, why can't they just make up the labels themselves? I don't think gist should be giving generic suggestions about UI design.
I'm definitely NOT suggesting to create the properties, only the labels, so it has nothing to do with best practice.
They will be making up labels for themselves for their own properties, but they will also want to have inverse labels for some of the gist properties. They can make up inverse labels for gist properties by squatting on the gist namespace.
I don't feel strongly one way or the other, just an idea to consider.
They can define inverses in their own namespace. Though that affects the reasoning around the gist predicates; is that what you mean by squatting in this case?
They can define inverses in their own namespace. Though that affects the reasoning around the gist predicates; is that what you mean by squatting in this case?
I misspoke, it is not namespace squatting. Here is what I meant. If they assert:
gist:hasMember gist:inverseLabel "is member of"^^xsd:string .
then they are making an assertion about a gist concept but they, in principle, should not do what amounts to changing the gist ontology for their local reasons. It may not do any harm, but supposse we decided to put the following in gist: gist:hasMember gist:inverseLabel "is a member of"^^xsd:string .
. Now it has two inverseLabels.
This came out of client request for the UI of a KG-driven production system. For example, suppose the UI calls for saying that person is a member of a committee, there is no property for describing that relationship from the member's perspective. We only have
hasMember
. The idea is to add and populate agist:inverseLabel
predicate to address this. For example:This is in lieu of what we have suggested in the past regarding suggested names for inverse properties, which we never did.