Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What should the basic shape of a catalog entrty look like? #1

Open
jeff-zucker opened this issue Nov 25, 2024 · 1 comment
Open

What should the basic shape of a catalog entrty look like? #1

jeff-zucker opened this issue Nov 25, 2024 · 1 comment

Comments

@jeff-zucker
Copy link
Member

jeff-zucker commented Nov 25, 2024

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. 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.

@jeswr
Copy link
Member

jeswr commented Nov 28, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants