Software release description

[bergus]

Hi!
The goals do state

Specifically not in scope for the first iteration is the description of software releases. Work on this can be investigated as a follow-up initiative

Has any work been done on this or is it already finished? I see that there is daop:release and doap:Version with a few properties, but they are not exactly sufficient for our purposes. We are looking into a linked data representation for managing automatic firmware updates of IoT devices. There might be multiple ways to install a version, like a fresh install or a small update or an update from the previous major version. Also each version might have different documentation.

All of these things don't seem to be covered by DOAP. What is the best practice here? Shall we roll our own ontology (in our own namespace), shall we combine multiple nearly-fitting ontologies? Can you suggest any good alternatives? Currently I found

• ADMS.SW 1.0 - which appears to be deprecated, and its successor seems to have a very different scope
• Codemeta, which draws from schema.org, has many more properties but doesn't even seem to distinguish between multiple release versions of the same application (or does it?)

I'm glad for any advise or pointers.

[kjetilk]

Good question! I don't know the answer, but my general thinking is that if the use case requires quite a lot of details and complexity, it might be best done as a separate ontology, but we might want to add a property to DOAP to tie it all together.

@tobyink made a few such ontologies, for example DOAP dependencies and DOAP changelogs, but I suppose neither match your requirements, but I mention them as examples.

[ewilderj]

Closing this out as I assume it worked out with a separate ontology. Please reopen if there's a way DOAP can help. I'll focus on seeing how we can incorporate @tobyink's work into either documentation or code.

[kjetilk]

Yes, this is interesting, because since then, these vocabs are all offline, I suppose  @tobyink doesn't maintain anymore, and also do not control ontologi.es anymore. So that may be reason enough to think about integrating them into DOAP itself.

There's also some work around machine readable specs that  @csarven is working on solid/vocab#92 which is relevant, so I think that's reason to have it open.

[csarven]

I've looked into expressing the release/version of a technical document (specification). Initially used doap:revision but then moved away from it mainly because (and happy to be corrected on this) 1) "Project" and "Specification" are conceptually different notions in DOAP, and 2) Version/revision seemed to be intended for a Project. So, decided to use schema:version since that also left some room to use Semantic Versioning as a literal value, e.g.:

<https://solidproject.org/TR/2024/protocol-20240512> <http://schema.org/version> "0.11.0" .