CR10 Asset. Duplicate property dct:type with two different meanings

Proposed resolution: Change cardinality of dct:type for Asset to 2..n with a note that at least one value for each of the two vocabularies need to be provided. In DCAT-AP, this property is optional with cardinality 0..n for Dataset.

Comment from Szabolcs Szekacs

I disagree. we should check what is the value for the user here. can you send me the assettype and the solutiontype vocabularies?

Do we really need to maintain two properties here??

@Szabolcs:

Solution type (current) :

- Tool

- Service

- Framework

We propose to replace this in CR40 : https://joinup.ec.europa.eu/asset/adms_revsion/issue/cr40-review-and-up…

Asset type taxonomy corresponds (or should correspond) to the list of building blocks of the EIRA. The taxonomy must be updated and reflected from the last version of the EIRA Architecture Building Blocks. This property is very important to relate asset between each other. IT is through this property that we can achieve solution architecture template (all solutions/framework/services connected together to realise a political objective - eID for example). This taxonomy will allow user to navigate from one solution to another and not only through a generic link 'related' like it is in the current Joinup. The relationships will have name that will help the user understand the context of a specific interoperability solution.

However, the list of ABB is long and selecting to which ABB a solution is corresponding not always easy at all.

If I understand correctly, the consensus is for dct:type to have cardinality 2..n, with at least one asset type and one solution type to be provided.

We will include this in the draft version of the revised profile. Of course, further comments are welcome.

Sorry for coming back to this issue, but for now, it seems that the only agreement made was about the cardinality of the dct:type (2..n)

What about the inclusion of the EIRA ABB list in the Asset type taxonomy ?

Today if I check the Asset Type Vocabulary I don't see much more than support for the interoperabilitylevel (political, legal, organisational, semantic and technical)

And so far the solution Type Vocabulary only specifies the new types (CR40):

• Policy
• Software
• Service
• Specification or standard
• Guideline or template

So only the level and type can be supported so far, but not yet the EIRA building block level, correct?

Regards,

Hans

Upon further reflection, it has been requested to put the cardinality of the property back to 1..n. The controlled vocabulary will be the EIRA vocabuylary that is under development.