semanticarts / gist

Semantic Arts gist upper enterprise ontology
Creative Commons Attribution 4.0 International
163 stars 18 forks source link

Add suggested labels for inverse properties #956

Open uscholdm opened 1 year ago

uscholdm commented 1 year ago

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 a gist:inverseLabel predicate to address this. For example:

gist:hasMember gist:inverseLabel "is member of"^^xsd:string .
gist:isIdentifiedBy gist:inverseLabel "identifies"^^xsd:string .
gist:isExpressedIn gist:inverseLabel "is language that expresses"^^xsd:string .

This is in lieu of what we have suggested in the past regarding suggested names for inverse properties, which we never did.

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

uscholdm commented 1 year ago

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.

rjyounes commented 1 year ago

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?

uscholdm commented 1 year ago

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.