You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of DCAT's most powerful features is the idea of an application profile - a specified shape for the catalog that conforms to DCAT but may have additions or restrictions. In particular, the Asset Description Metadata Schema - ADMS is an application profile of DCAT created by the EU as part of the now defunct W3c Government Linked Data Working Group. It has a number of features that fit in with both the short and long term goals of this project. ADMS puts its emphasis on the resources rather than the catalog. It is designed to work as either a hard-coded catalog or as one constructed from syndication or federation. It is also designed to specifically work with "semantic assets" which can include vocabularies, specifications, and schema.
A catalog using ADMS has two clearcut ways to relate the catalog to other conceptual structures. The adms:supportedScheme predicate ties the catalog to a document such as a SHACL shape that describes the structure of the catalog entries. The adms:themeTaxonomy predicate ties the catalog to a SKOS concept scheme which can be used to categorize the entries. SKOS is also used to define types within the catalog. Instead of rdf:type, ADMS uses dcterms:type and specifies that its value be a skos:Concept. The use of SKOS to internally structure the catalog means that all catalogs have a very similar shape but also room to flexibly customize in an interoperable way.
I propose that we create our own DCAT application profile that is based on ADMS. It would need to extend the idea of an adms:Asset, which is itself a subclass of dcat:Resource. These terms are most often used to refer to documents but both DCAT and ADMS explicitly say that anything can be viewed as an Asset/Resource. This means that people, events, products, services, creative works, can all be cataloged. This idea is similar to the definition of a sioc:Community which treats all of these types of things as potential parts of the community.
I propose the diagram below as the basic catalog shape. It is compliant with both ADMS and DCAT and follows the ADMS usage for all predicates. I have left out, for the moment, the question of how we access an Asset (e.g. a download point) , for which see issue #2 and how Assets relate to each (e.g. one software depends on another), for which see issue #3.
The text was updated successfully, but these errors were encountered:
This sounds like a sound approach to me. I would propose the creation of a PR with the SHACL shape that can be used to validate catalog entries according to the shape of entry that you have described above.
I would suggest using shape conversion tools to assist you in generating these shapes from their OWL/RDF definitions.
What should the basic shape of a catalog entrty look like?
Reccommendation : create an ADMS/DCAT profile tailored to our needs.
The Data Catalog - DCAT and related vocabularies are recommended as best practice by ODI. Governments have created local variants of DCAT in the EU, the U.S. and other places.
One of DCAT's most powerful features is the idea of an application profile - a specified shape for the catalog that conforms to DCAT but may have additions or restrictions. In particular, the Asset Description Metadata Schema - ADMS is an application profile of DCAT created by the EU as part of the now defunct W3c Government Linked Data Working Group. It has a number of features that fit in with both the short and long term goals of this project. ADMS puts its emphasis on the resources rather than the catalog. It is designed to work as either a hard-coded catalog or as one constructed from syndication or federation. It is also designed to specifically work with "semantic assets" which can include vocabularies, specifications, and schema.
A catalog using ADMS has two clearcut ways to relate the catalog to other conceptual structures. The
adms:supportedScheme
predicate ties the catalog to a document such as a SHACL shape that describes the structure of the catalog entries. Theadms:themeTaxonomy
predicate ties the catalog to a SKOS concept scheme which can be used to categorize the entries. SKOS is also used to define types within the catalog. Instead ofrdf:type
, ADMS usesdcterms:type
and specifies that its value be askos:Concept
. The use of SKOS to internally structure the catalog means that all catalogs have a very similar shape but also room to flexibly customize in an interoperable way.I propose that we create our own DCAT application profile that is based on ADMS. It would need to extend the idea of an
adms:Asset
, which is itself a subclass ofdcat:Resource
. These terms are most often used to refer to documents but both DCAT and ADMS explicitly say that anything can be viewed as an Asset/Resource. This means that people, events, products, services, creative works, can all be cataloged. This idea is similar to the definition of asioc:Community
which treats all of these types of things as potential parts of the community.I propose the diagram below as the basic catalog shape. It is compliant with both ADMS and DCAT and follows the ADMS usage for all predicates. I have left out, for the moment, the question of how we access an Asset (e.g. a download point) , for which see issue #2 and how Assets relate to each (e.g. one software depends on another), for which see issue #3.
The text was updated successfully, but these errors were encountered: