developmentStatus - propose the addition of the property into schema.org

[moranegg]

With SCIWG CodeMeta task force we are working on the adoption of the CodeMeta additional terms into schema.org.
We found that the property developmentStatus has an equivalent pending property in schema.org named creativeWorkStatus, which might be confusing to use with software.

If we propose the very similar property developmentStatus, it might be rejected as is.

We have three options:

1. renaming to creativeWorkStatus and open an issue we are using the term as is and push for its acceptance into schema.org
2. renaming to status and open an issue we wish the pending property be modified to be more inclusive (and less difficult to understand in the software/academic context)
3. ask for the developmentStatus to be added to the SSC class and hope for the best ;-)

References:
The closed issue in schema.org: schemaorg/schemaorg#987
The pending property: https://schema.org/creativeWorkStatus

[RichardWallis]

I would suggest an option 4.

Propose a new property developmentStatus - a sub-property of creativeWorkStatus - with a domainIncludes of SoftwareSourceCode

[mbjones]

I think the creativeWorkStatus with its ability to use a DefinedTerm would allow us to reference, for example, the terms from the repostatus.org vocabulary (e.g., https://www.repostatus.org/#active). The question is, do we want to require such a typology, or do we want to leave it open to multiple different typologies. If the former, then it makes sense to create a subproperty. If the latter, I see no no need for a subproperty.

I suspect getting creativeWorkStatus renamed would be a difficult sell, especially if we are not talking about expanding its domain. Seems fine to me for us to use creativeWorkStatus, possibly with a defined term vocabulary constraint.

[RichardWallis]

Getting creativeWorkStatus renamed would be a difficult sell, due to the broad coverage of CreativeWork and its many sub-types.

Reference to the repostatus.org vocabulary highlights another potential option.

If there is an agreed, finite set of potential status values, the solution could be to propose a developmentStatus property for use on the SoftwareSourceCode type, with an enumeration (DevelopmentStatusType) as its expected value. There would then be enumeration members defined for each status value (ActiveStatusType, UnsupportedStatusType, etc.). The description of each could reference of their repostatus.org equivalent if thought appropriate.

For those unfamiliar with enumerations in Schema.org check out the bookFormat property, its associated enumeration BookFormatType and enumeration members Hardcover, Paperback, etc.

[moranegg]

Thank you @RichardWallis for your input, I really like your proposal.

Let's keep developmentStatus as the name of the CodeMeta term and prepare a proposal for schema.org with an enumeration.

[dgarijo]

On the one hand, I like the proposal of having an enumeration: it keeps things under a controlled vocabulary easing interoperability. On the other hand, people are very likely to add their own types to the enumeration; or not use the enumerated types at all. Having more restrictions makes Codemeta more difficult to adopt.

This property has also a mutable aspect which makes it difficult to maintain (the status may change).

[mfenner]

The Force11 Codemeta Task Force suggests adopting repo status (from repostatus.org) as the enumeration for development status.

[proycon]

I agree repostatus terms provide an excellent vocabulary and we should recommend its usage, but it should not be a requirement and people should be free to use other vocabularies.

Codemeta.jsonld already defines developmentStatus as:

"developmentStatus": { "@id": "codemeta:developmentStatus", "@type": "@id"},

so if I interpret things correctly the values should be identifiers and if we merely use a repostatus string like "active" that would be interpreted in local scope?

The repostatus vocabulary itself wasn't properly formalized as an ontology yet, I just attempted to do so now in jantman/repostatus.org#48 . This should hopefully improve the interoperability.

(Something similar plays with licenses by the way, where I'd recommend using full SPDX URIs)