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

Add support for DCAT-AP v3 #22

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

jahow
Copy link
Contributor

@jahow jahow commented Nov 25, 2024

Implements #15

Remaining to do:

  • Update templates
  • Try it out in the editor
  • Maybe do some kind of automatic upgrading to v3 on update-fixed-info?

@@ -327,6 +340,26 @@
</xs:sequence>
</xs:complexType>


<!-- dcat:DatasetSeries -->
<xs:complexType name="DatasetSeries_type">
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: I could not find an actual record describing a DatasetSeries so this is purely theoretical for now; open to any suggestions/help, thanks!

<dct:hasVersion rdf:resource="{{key}}"/>
</snippet>
</template>
</for>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a need for keeping DCAT-ap 2 compatibility in the editor ?
Since DCAT 2 and 3 are pretty similar, maybe the update-fixed-info.xsl should automatically migrate any DCAT-ap 2 records being edited.

<xs:sequence>
<xs:element ref="dct:first" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="dct:last" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="dct:next" minOccurs="0" maxOccurs="unbounded"/>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe these elements should be in the dcat namespace.
As far as I understood, the dct:next should be at the dcat:Dataset level, alongs with a dcat:prev elements.

@CMath04
Copy link
Collaborator

CMath04 commented Dec 10, 2024

Reading a bit through the vocabulary specification (https://www.w3.org/TR/vocab-dcat-3/#dataset-series-specification) and the application profile implementation (https://semiceu.github.io/DCAT-AP/releases/3.0.0/),

From my understanding, the idea is to have this type of RDF :

<rdf:RDF ...>
    <dcat:Catalog>
        <dcat:record>
            <dcat:CatalogRecord>
                <!-- some record -->
            </dcat:CatalogRecord>
        </dcat:record>
        <dcat:dataset>
            <dcat:DatasetSeries rdf:about="https://example.com/dataset/some-data-collected-annually">
                <dct:title xml:lang="en">Some data collected annually</dct:title>
                <dct:description xml:lang="en">With a description</dct:description>
                <!-- Any other field from dcat:Dataset class -->

                <dcat:first rdf:resource="https://example.com/dataset/some-data-collected-for-year-2020"/>
                <dcat:last rdf:resource="https://example.com/dataset/some-data-collected-for-year-2022"/>
            </dcat:DatasetSeries>
        </dcat:dataset>
        <dcat:dataset>
            <dcat:Dataset rdf:about="https://example.com/dataset/some-data-collected-for-year-2020">
                <dct:title xml:lang="en">Some data collected for year 2020</dct:title>
                <!-- Any other field from dcat:Dataset class -->

                <dcat:inSeries rdf:resource="https://example.com/dataset/some-data-collected-annually"/>
                <dcat:next rdf:resource="https://example.com/dataset/some-data-collected-for-year-2021"/>
            </dcat:Dataset>
        </dcat:dataset>
        <dcat:dataset>
            <dcat:Dataset rdf:about="https://example.com/dataset/some-data-collected-for-year-2021">
                <dct:title xml:lang="en">Some data collected for year 2021</dct:title>
                <!-- Any other field from dcat:Dataset class -->

                <dcat:inSeries rdf:resource="https://example.com/dataset/some-data-collected-annually"/>
                <dcat:prev rdf:resource="https://example.com/dataset/some-data-collected-for-year-2020"/>
                <dcat:next rdf:resource="https://example.com/dataset/some-data-collected-for-year-2022"/>
            </dcat:Dataset>
        </dcat:dataset>
        <dcat:dataset>
            <dcat:Dataset rdf:about="https://example.com/dataset/some-data-collected-for-year-2022">
                <dct:title xml:lang="en">Some data collected for year 2022</dct:title>
                <!-- Any other field from dcat:Dataset class -->

                <dcat:inSeries rdf:resource="https://example.com/dataset/some-data-collected-annually"/>
                <dcat:prev rdf:resource="https://example.com/dataset/some-data-collected-for-year-2021"/>
            </dcat:Dataset>
        </dcat:dataset>
    </dcat:Catalog>
</rdf:RDF>

Now, we don't necessarily need for this to be a single metadata record in GeoNetwork.
Hence, I see two big approaches for implementing this:

  • Option 1 is to have single metadata records containing everything at once. The md editor would list all the datasets in a single tab (or many tabs) and the user would be able to edit all of them at once.

  • Option 2 is to have a separated standalone dcat:DatasetSeries metadata record and links between all datasets by using.

I feel option 2 offer the more flexibility, especially for indexing, but can get quite complex. For every linking operations, the links between series and datasets (dcat:inSeries <=> dcat:first & dcat;last) need to be updated. As well as maintain all the links between related datasets (dcat:prev & dcat:next).
On the other hand, option 1 seems easier to use from user perspective but might result in giant metadata records and it not easy to opt in from existing dataset record which need to be fully migrated. It also get hard to correctly index.

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

Successfully merging this pull request may close these issues.

2 participants