CR21 Asset. Remove adms:last, adms:next, adms:prev properties and replace them with a property dct:isVersionOf

Proposed resolution: Remove adms:last, adms:next, adms:prev from Asset. Add dct:isVersionOf as optional property with cardinality 0..n to Asset. This is in line with DCAT-AP.

CR1             

Remove adms:last, adms:next, adms:prev properties and replace them with a property dct:isVersionOf

Issue/problem

The versions organisation is maybe a bit difficult to understand in ADMS, which makes the properties adms:last, adms:next and adms:prev unused  by metadata publishers. They do not grasp which asset to relate to which other and using which property. As all assets can have a version number (through property owl:versionInfo), it may be sufficient to have a single property dct:isVersionOf to relate an asset to its releases. The order of the releases can be deducted from the version number. This proposal is aligned with DCAT-AP.

The fact that a release of an asset must be described using the asset class is also sometimes not well understood. Solutions publishers expect very often to find a typical structure Solution – Release – Distributions, as it is the case in SourceForge or GitHub. While the current ADMS-AP specifications allows to relate releases to an asset, the metadata used to describe a release and the asset are (and should) not be the same. Typically, the version notes and version number should be mandatory for a release (while optional or not existing for the asset) and the description should be optional (while mandatory for an asset). There is no clear proposal of what should be done to tackle these issues without drastically changing the data model of ADMS-AP (which is based on ADMS and DCAT-AP). But this discussion should be opened in the WG (if there is one).

Proposal

The lightest proposal would be to remove the properties adms:last, adms:next and adms:prev related to the class adms:Asset and add a new property dct:isVersionOf associated to the same class with range adms:Asset and cardinality 0..N (recommended property).

However, the question of how assets are related to releases and what should be the difference of metadata between the two concepts should be opened.

Comment from Szabolcs Szekacs

Why is the version at the asset level?

shall we not have three levels for every asset:

1. solution level (e.g. Libreoffice

2. version level (e.g. Libreoffice v12

3. distribution level (libreoffice v12 for windows)

This is already done for software, will it be treated the same for all type of assets?

@Szabolcs,

The dct:versionOf would be used to relate an asset to its different releases. We need to somehow make a link between the solution and the release. That's what dct:versionOf would be used. Then we can know the order of the release based on the owl:versionInfo property.

@Makx, to clarify the CR: DCAT and ADMS are based on a two-layer model Asset - Distribution. For software solutions, the "release" business concept is therefore not a separate ADMS concept and must be described using the Asset concept as well. However, this does not make a lot of sense as you don't expect to have the same information about the solution and about its releases.

For a "release" concept, you are much more interested in the version notes (or release notes) and the version info than in a general name of the release or a description...

I see 2 options here:

1) Leave things are they are. Joinup could always display a three-level model even if it described with 2 levels in the back. But this raise question about harvested information: metadata publisher will use a two-layer model to describe, among others, their software, and Joinup may not be able to differentiate a solution from a release.

2) Create a subclass 'AssetRelease' of 'Asset' with some shared properties but with cardinalities different. We should also have a relationship dct:versionOf between the superclass and the childclass (I don't know if that is something possible to model but I guess so, through a property dct:versionOf with domain adms:Asset and range adms:AssetRelease). The assetRelease could also be the place for putting more specific info about software solutions (like issues link, metrics, etc.) that we could retrieve from the ADMS.SW softwareRelease class.

What do you all think? This a very important discussion which can potentially have a a big impact on metadata publisher.

The issue of grouping Datasets in some sort of series (temporal, spatial) has come up in the revision of DCAT-AP. In that discussion, no commonly accepted solution was reached.

If it is really necessary to distinguish the Solution level from the Version level, one possible solution could be to model the Solution as a prov:Collection http://www.w3.org/TR/prov-o/#Collection which is defined as "an entity that provides a structure to some constituents, which are themselves entities". You could then define the properties you need to describe the Solution, and link to the Versions using either dct:hasPart or prov:hadMember, and link from the Version to the Solution with dct:isPartOf or prov:wasMemberOf.

A DCAT-AP compliant system would not need to understand this approach and would just treat the Versions as self-standing Assets, but a system that understands PROV would be able to understand the relationships.

So this means that adms:Asset would be used to described the release of a solution, while prov:Collection would be used to describe the solution itself.

If we go for this approach, we need to review the fields of the adms:Asset so that it is adapted to the release concept. And we need to define the properties for prov:Collection.

I'd like to hear the opinion of the other implementers and see whether this would be a good idea or not...

#8 what would be the impact of this approach on the need to align ADMS with the EIRA?

(e.g. in terms of relationships)

First of all, we will remove adms:last, adms:next, adms:prev from Asset. We will not add dct:isVersionOf as optional property with cardinality 0..n to Asset for the moment.

The issue of how to model the three-level structure for software is still pending and needs further discussion.