Document .py API + schema config markup for deprecating (rather than marking as supersededBy) terms

[danbri]

Sometimes usage of a term is discouraged, with no clear, obvious and exact successor. In such cases we need a way (in the schema config and site UI) for indicating this. We should document the vocabulary (whether SKOS/OWL or custom) and implement something appropriate in the site codebase.

• first use case: UserComments, https://github.com/schemaorg/schemaorg/issues/170
• Note that api.py defines two related functions, superseded(self, layers='core') and supersededBy(self, layers='core'). We need to be clear how successor-less deprecation affects this API.
• what do most other vocabs use?

[danbri]

Strawman proposal:

For now let's use http://schema.org/deprecatedSchemaTerm: True, purely as an implementation detail. We have enough other enquiries open that I don't want to waste time finding the perfect answer here. The markup will only be used in our repo and code right now, and we can evolve it later.

[mfhepp]

FYI: GoodRelations uses foo:SomeConceptualElement owl:deprecated true.

for deprecated elements and tracks successor elements directly via alignment axioms, like owl:equivalentProperty, owl:equivalentClass, and owl:sameAs.

The advantage of this approach is that you provide a link to the current element which at the same time assures compatibility with old data. The current element is simply that of the set linked via owl:equivalentProperty, owl:equivalentClass, and owl:sameAs. that is not marked as deprecated. A downside is that the history of names is lost (e.g. you will not see the sequences firstName -> secondName -> thirdName, but instead just realize that thirdName is not deprecated and firstName and secondName are equivalent but deprecated).

But in many cases you do not need the history of naming.

Schema.org could relatively easily adopt the same pattern.

[unsteady]

Copying my answer to @danbri at https://plus.google.com/+DanBrickley/posts/cMvTnqkXL7z I'm not sure the use in LOV indicates any significant trend, given that more than 95% of vocabularies have absolutely no policy regarding depreciation, they just throw terms between versions without notice. And in fact most vocabularies have no versioning policy at all, unfortunately. Exploring the data I found that about 12 vocabularies use indeed owl:deprecated "true", a little less use some value of vs:term_status "deprecated", "archaic" or even "depricated" (sic). Those values being uncontrolled text, I would not recommend it.

[dr-shorthair]

'deprecated' by itself begs the question. Accompanied by dct:isReplacedBy pointing to the replacement is better. .

The 'registry' vocabulary http://purl.org/linked-data/registry also has http://purl.org/linked-data/registry#status with values selected from http://purl.org/linked-data/registry#Status which provides a richer set of status values.

[rvguha]

Rather than a boolean, can we have a 'termStatus' attribute? I can think of values other than deprecated.

guha

On Thu, Apr 30, 2015 at 10:41 AM, Dan Brickley [email protected] wrote:

Strawman proposal:

For now let's use http://schema.org/deprecatedSchemaTerm: True, purely as an implementation detail. We have enough other enquiries open that I don't want to waste time finding the perfect answer here. The markup will only be used in our repo and code right now, and we can evolve it later.

— Reply to this email directly or view it on GitHub https://github.com/schemaorg/schemaorg/issues/465#issuecomment-97893295.

[mfhepp]

+1

[danbri]

I'll put something together as an admin: extension, to give us wiggleroom to evolve it.

[danbri]

Where we ended up: superseded as relations amongst terms, plus "Attic" as a term status (or area of the site, if you prefer) for terms that are somewhat hidden away. There's doubtless more to do here; I'll move this issue to suggestions-questions-brainstorming repo to keep it open for discussion.

[RichardWallis]

See issue #7 for the context of the move from the main Schema.org issue tracker to this repository.