Add existing CreativeWork as an expected type for existing description property

[gmackenz]

Currently the description property expects only Text. This is insufficient if there is additional information that needs to be conveyed with the text string (like authorship, licensing information, expiration date, etc.). I would propose we allow descriptions to also be CreativeWorks which has such properties allowing attaching various annotations to a text string.

This is proposal comes from Google to allow us to better handle/process description text for media and other content.

[RichardWallis]

I believe I can see where this is coming from - presuming that this is referring to the use case of types of Things (eg. Products) that do not have such properties, and not CreativeWorks / CreativeWork subtypes (as they already have those properties).

However, it is not that simple. For example, the expires property in a CreativeWork linked from the description property of a Product would describe when the CreativeWork will expire, not the Product it is linked from. The same is true for the other suggested as useful properties, they are describing the CreativeWork, not the Thing that has that CreativeWork as its description.

I can see the benefit of being able to have a CreativeWork as a description - eg. a BlogPosting acting as a quality description of a Place. But it would be logically incorrect to assume that properties of a linked CreativeWork description [other than its textual content] expand the information about the entity that links to it.

[WeaverStever]

Isn't this what the https://schema.org/about does for us?

[RichardWallis]

about and description could be considered to be inverse of each other in this context, yes. As in the content of the [description] CreativeWork will be 'about' the Thing it describes. For mark up simplicity you might want to explicitly assert the relationship from the Thing end.

However, this bit of semantics doesn't address what appears to be the main suggestion in this issue - that properties (expires, author, license, etc.) of the describing CreativeWork, would be informational as to the status of the Thing it is describing.

[gmackenz]

Thanks for the feedback Richard. That was the intent, the string of text is a CreativeWork in of itself with attributes that are not about the Product/TVEpisode this text string is a description of. The properties on CreativeWork would add additional context/information just about the string of text.

Is there another way we can attach dates, licensing, sources to a string value? Would we need a new type to capture the text value and additional information about the text? What would that look like? PriceSpecification?

[RichardWallis]

@gmackenz Now you explain it that way I am more comfortable.

However, are you not proposing what is already possible via the subjectOf property?

[gmackenz]

@RichardWallis I don't believe that would work as that is for the object and not applicable directly for the description text of that object. So for example: a TV programming data feed using schema.org markup for a TVEpisode for a TV program that includes a description string supplied from a NBC source that is only contractually available for 6 months. We can't capture that data currently in schema.org as far as I can tell. I don't believe subjectOf would work for that usage.

[RichardWallis]

@gmackenz now you flesh out that scenario it appears a bit too specific for linking to via the description property.

A simple Text description, as you indicate, has no information about its authorship, licensing, expiry date etc. Hence to capture that sort of thing you are looking to a CreativeWork or subtype thereof.

With current Schema capability that would be a CreativeWork (eg. Article) that would be about the program. Via the inverse the program's markup could indicate that it is subjectOf the article.

The only difference I am picking up from your description of the need, is that somehow you want to indicate that the relationship between the entity (TV Program) and its description will expire. Or is it you want the link to remain but indicate that the descriptive text has past its expires data.

[github-actions]

This issue is being nudged due to inactivity.

[gmackenz]

Revisiting this as there is growing need for Google to have a means of annotating text with additional information (localizing restrictions, time of use, etc.) for the 'description' text that may be provided by content providers for MediaObjects (mostly VideoObjects for now such as Films, TV Shows, TV Episodes, etc.).

Either we can expand the domainIncludes of description to include both Text and CreativeWork and use the latter's properties for additional information about the description text content.

:description a rdf:Property ;
    rdfs:label "description" ;
    :domainIncludes :Thing ;
    :rangeIncludes :CreativeWork,
        :Text ;
    rdfs:comment "A description of the item." ;
    owl:equivalentProperty dc:description .

Or we could instead expand the domainIncludes of description to include both Text and a new TextObject subtype of MediaObject. A new MediaObject subtype of TextObject would allow us to have specific properties later in regards to text as opposed to audio, video, etc.

:TextObject a rdfs:Class ;
    rdfs:label "TextObject" ;
    :isPartOf <https://pending.schema.org> ;
    rdfs:subClassOf schema:MediaObject ;
    rdfs:comment "A text file." .

:description a rdf:Property ;
    rdfs:label "description" ;
    :domainIncludes :Thing ;
    :rangeIncludes :Text,
        :TextObject ;
    rdfs:comment "A description of the item." ;
    owl:equivalentProperty dc:description .

[philbarker]

See also #1379 and #276 and suggestion of treating the (structured) abstract of an academic work as a CreativeWork.

[RichardWallis]

In principle I support your second (TextObject) option - using some of the general CreativeWork subtypes such as VideoObject or Sculpture would not be particularly useful as a description.

In practice if we implemented TextObject, we should handle at least in the description of the type, some of the inevitable questions that would arise. Such as, is this type for plain text only or is html, markdown, or other text formats acceptable.

[gmackenz]

In practice if we implemented TextObject, we should handle at least in the description of the type, some of the inevitable questions that would arise. Such as, is this type for plain text only or is html, markdown, or other text formats acceptable.

So what is allowed for Text currently?

I believe TextObject's text should be pretty much text format-agnostic.:

"A text file. The text can be unformatted or contain markup, html, etc."

Edited my contribution: 2c3a595