In recent conversations, the idea has come up to convert ADMS-AP into a (possibly extended) DCAT-AP. This would mean that the ADMS-specific classes AssetRepository, Asset and AssetDistribution would be replaced by the DCAT classes Catalog, Dataset and Distributions. The ADMS classes are sub-classes of the DCAT already, and the ADMS specification at W3C already declares "ADMS is a profile of DCAT".
Making ADMS-AP a direct profile of DCAT would also address Willem van Gemert's comment in his message to the list asking for an explanation of what ADMS offers compared to DCAT.
The question to consider would be whether ADMS-AP could be replaced by DCAT-AP as it is now, or that it would require an extension to DCAT-AP. An important consideration would be how an exended profile affects interoperability, for example if the descriptions of the assets were to be harvested into the European Data Portal that uses the existing, revised DCAT-AP.
Comments
Hello:
The same problems happens in the cases we have implemented federation with joinup using ADMS.AP. It has been a great effort and we will have to do it all again.
I totally agree that the final objective of DCAT and ADMS can be very similar conceptually, the federation of assets. If we can agree on something stable for both scopes could be interesting. However, this will probably increase the complexity of the standard as we have seen in the evolution of ADMS to ADMS.AP.
Regards
Some quick thoughts on this - please not that I am not an expert at all, just saw the issues using ADMS-AP on Joinup.
It is already hard to describe standards and software using one specification, as it is demonstrated by the various change requests we collected in this exercise.
I am a bit afraid, that trying to describe datasets, standards and software using one specification, would make that specification even less understandable.
Fully support better alignment between the two standards (e.g. AssetRepository can become catalogue, etc), a bit more careful with full replacement.
As also highlighted in CR21 software is usually described using 3 layer approach (Solution – Release – Distributions), while standards and data use 2 layer descriptions.
Another issue with re-using 100% the DCAT and extending it may arise with the use of themes, unless the standard allows to use different controlled vocabularies for themes for datasets / standards and software.
So, in short - I am all for better alignment, a bit more cautious with complete re-use of DCAT and creating the new specs as an extension...
As Szabi said, I think making ADMS-AP a extension of DCAT-AP would require to many changes in the specifications. This will make the switch to the new specs really difficult for ADMS-AP implementers...
Is this something we should still consider further?
As the ADMS-AP are subclasses of DCAT-AP I think you can use inference to extract data, so I would keep ADMS-AP and DCAT-AP separately.
See:
http://www.dataversity.net/introduction-to-triplestores/
http://docs.openlinksw.com/virtuoso/rdfsparqlrule.html
I think there are two perspectives here:
My suggestion was to look at ways that an application profile can serve both purposes. If this group decides that only perspective 1 needs to be considered, it means that publishers of assets that want to also get their assets visible in EDP need to run two parallel exports, one for Joinup and one for EDP. The Publications Office is already doing this, and they asked me if this could maybe be rationalised by having one profile that serves both.
The way this could be done is to define DCAT-Joinup-AP in such a way that it does not violate the rules of DCAT-AP, meaning that it contains, at least, all mandatory properties and also contains the recommended properties but only as far as that information is available for assets. Please note that the DCAT-AP has relatively few mandatory properties (e.g. description and title for Dataset and just accessURL for Distribution). The Joinup profile can make properties mandatory that are recommended or optional in DCAT-AP, and can make recommended what DCAT-AP has as optional, without losing the interoperability with the general DCAT-AP profile.
The only fundamental change would be that the revised profile would not specify classes adms:Repository, adsm:Asset and adms:AssetDistribution but use dcat:Catalog, dcat:Dataset and dcat:Distribution instead. I do agree with Emidio that inference rules would enable an aggregator to understand that the ADMS classes are in fact subclasses of DCAT classes, but this means that you require an aggregator like EDP to use an inference engine to make the inference. They might just decide that they don't know what an adms:Asset is and refuse the feed.
On the other hand, Joinup would have no problem being backwards compatible: it would be able to accept both upgraded feeds with DCAT classes and legacy feeds with ADMS classes.
So the questions may be: what is the practical advantage of keeping the ADMS classes, and what is the disadvantage of using the DCAT classes?
Given that the ADMS-AP is used for describing, among others, software and services, I would recommend keeping it distinct from the DCAT-AP. Merging the two can create confusion.
The proposal is not to merge the two profiles. For keeping things clear, let's continue to call the revised Joinup profile ADMS-AP (version 2.0) to distinguish it from the DCAT-AP for data portals in Europe, version 1.1.
The proposals has two main aspects:
The rationale is that metadata published conforming to ADMS-AP 2.0 would be fully interoperable with DCAT-AP 1.1, making it easy for 'general' data portals (e.g. EDP) to accept ADMS-AP 2.0 data without having to invoke an inference engine and without, I think, any adverse affects on Joinup.
+1 @Makx