Add predicate gist:describes?

[rjyounes]

In the course of removing inverses - see issue #506 - we opted to keep isAbout and remove isDescribedBy. However, these are semantically not inverses. To repeat the example on the related PR #813:

On further thought, describes is the proper inverse of isDescribedBy; isAbout means something a bit different. Consider: the anatomy of my foot is described by Gray's Anatomy. We can say that the book describes the bone structure of my foot, but not that it is about my foot. One solution is to replace isDescribedBy with describes (for brevity) and keep isAbout as well.

The proposal here is to bring back isDescribedBy (or describes) with a clearly different meaning than aboutness. The open question is whether there is sufficient value to such a predicate to warrant its inclusion in gist.

[dylan-sa]

I agree that aboutness and description come apart, though maybe in a different way.

Description is usually taken to be a purely linguistic thing. (From Oxford dictionary: "[A] spoken or written representation or account of a person, object, or event.") A document or book can describe Abe Lincoln by attributing properties to him (that he was honest, for example). Such a text would be about Abe Lincoln. The movie Lincoln w/ Daniel Day Lewis is also about Abe Lincoln, but it doesn't describe Lincoln; it depicts him, like his portrait in the National Portrait Gallery.

Aboutness is a more general representational thing--movies, paintings, mental states (like dreams), and books can all be about things. Descriptions--while they are usually about something, too--are linguistic representations.

I think this could help us distinguish describes from isAbout if we decide there is value in adding it.

[rjyounes]

The film example is good. I don't think of a painting as being about its subject; it represents it. In that sense "has subject" might cover the about cases in a unifying way (haven't thought this through, there may well be counterexamples). Text can both describe and/or be about, with a lot of overlap but some differences, as in my example above.

[uscholdm]

I think this could help us distinguish describes from isAbout if we decide there is value in adding it.

We already have gist:description, if we add anything new, it should be clearly delineated.

[rjyounes]

gist:description is a datatype property. The question is whether we want another object property.

[uscholdm]

Exactly. If we add something similar to this ('describes' and 'description' share the same root word), we should have a clear understanding of why we need both.

[rjyounes]

Agreed. I'm not suggesting that we should adopt such a property, merely raising it as a question.

[Jamie-SA]

Discussion:

• Possibly a subproperty of gist:isAbout?
• Two dimensions: primarily about vs "just" some connection, plus some format issue (text vs ?)
• Is there enough distinction to be useful to include in gist?

Dylan will work on creating a potential PR to review.

[uscholdm]

Is there a clear justification for having this property? That would seem to come before a PR implementing the idea.

[dylan-sa]

Right, I think the idea was just to give us something more concrete to look at, but that is a fair point. Here are a couple reasons in favor of having an object property like isDescribedBy or describes in gist:

1 - Bundles of properties: Here is a use case I've seen on a couple client projects. There is a string of text that bundles together a set of properties, which are usually represented as codes. Suppose a shipment is related to a string of text: 'P&G:GA:2022'. 'P&G' means the shipper is Proctor & Gamble, 'GA' means the origin of the shipment was Georgia, and '2022' indicates the date of the shipment. Though a shipment may have all of these properties, it is clear that there is not enough packed into the string to identify one particular shipment. If the shipment is not identified by the string, then a natural alternative is to say that it is merely described by the string.

A couple real world examples I've seen:

• Charge codes, which are strings of text carrying information about a time charge. The text on its own isn't enough to identify a single time charge, but it does describe the time charge as having various properties. A client-specific object property isDescribedBy has been used for this purpose.
• 'Ambiguous descriptors' of symbols at Platts: Strings of text that describe symbols but don't uniquely identify them. I believe a datatype property hasDescription was used in this context.

2 - In favor of having an object property, specifically: As Michael mentioned, we do have the datatype property gist:description, so we should consider whether that might handle the use cases above. While I think a datatype property might handle the symbol descriptors case, it wouldn't handle the charge code case. Similar to how IDs are treated as IRIs in gist (to say who they've been allocated by, etc.), it would also be useful to have description objects that can have various properties of their own. The charge code above is one example of this--it's helpful to represent the charge codes as objects because one way of representing them might be superseded by another.

[Jamie-SA]

@uscholdm you missed the discussion, but if you'll read the comments I added you'll see that there was no decision made but that there seemed enough support that it was worth considering. Dylan offered to work on making the case for it to be added as they have real use cases of how they would like to use it.

[uscholdm]

If the shipment is not identified by the string, then a natural alternative is to say that it is merely described by the string.

That is exactly what gist:description is for.

'Ambiguous descriptors' of symbols : Strings of text that describe symbols but don't uniquely identify them. I believe a datatype property hasDescription was used in this context.

That might have been before gist:description came about, not sure about that.

@dylan-sa acknowledges that gist:description will suffice for these examples. I don't quite understand the example arguing for the need for an object property, so it's a bit subtle, or I'm missing something obvious. In any event, if only one of the several examples that come to mind seem to call for an object property, that is likley not sufficient justification for putting it into gist.

If a client ontology requires it, then :hasDescription is a good name, as it is semantically identical in naming to gist:description, with our object prop naming convention. In that case a skos:note stating that semantic equivalence would be warranted.