search

cessda / cessda.cvs.two

Apache License 2.0
0 stars 2 forks source link

Design: SKOS/RDF amendment #387

Closed cessda-bitbucket-importer closed 1 year ago

cessda-bitbucket-importer commented 2 years ago

Original report on BitBucket by Taina Jääskeläinen.

This is the issue to handle changes to SKOS/RDF.

Process:

‌

cessda-bitbucket-importer commented 2 years ago

Original comment by Taina Jääskeläinen.

  <div class="preview-container wiki-content"><!-- loaded via ajax --></div>
  <div class="mask"></div>
</div>

cessda-bitbucket-importer commented 2 years ago

Original comment by Darren Bell.

From: Taina Jääskeläinen (TAU) [[mailto:email address removed](mailto:email address removed)]
Sent: 27 April 2022 13:49
To: Bell, Darren S <[email address removed](mailto:email address removed)>
Subject: RE: SKOS/RDF for DDI vocabularies

 

Hi Darren,

I made an issue and put the example vocabulary there.

https://github.com/cessda/cessda.cvs.two/issues/387

I attach the vocabulary here as well.

 Or have you had time to look at these already?

Would be nice to have a timetable if possible. Let me know, we have a CVS sprint meeting tomorrow Thursday.

 Even though I’m giving you more work, hoping you were able to take some time off during Easter!

 All the best,

Taina

cessda-bitbucket-importer commented 2 years ago

Original comment by Darren Bell.

Hi Taina. I’m on holiday this week but I will look at this next week. My first observation is that we cannot have different publication dates for the concept scheme per language e.g. in version 1 there is a publication date of 2019-11-01 for English. 2019-11-15 for Danish and 2019-12-01 for Finnish. The ConceptScheme can be one (and only one) object with multiple translations - which themselves are not objects. This is really critical for DDI Compliance. Anyway, I’ll produce the example SKOS by end of next week (Friday 6th). I will need to look at other non-SKOS properties (Dublin Core, possibly DCAT etc.) to handle some of the metadata like “URN” and “Agency”. Best, Darren

cessda-bitbucket-importer commented 2 years ago

Original comment by Taina Jääskeläinen.

The publication (could also be called revision) dates were there only because I understood that there would be one concept scheme version but whenever any content in itself is changed, a new (revision) date for the ‘whole package file', without the concept scheme version changing.

How will systems otherwise know that some content has been changed? Otherwise, if a new language is added and there is no need for concept scheme changes for some years (i.e. no version change), will systems/DDI Alliance not show that language content for years?

Or is the intention that all harvesting systems harvest the CV at regular intervals, changes or no changes?

cessda-bitbucket-importer commented 2 years ago

Original comment by Darren Bell.

Hi Taina - there isn’t really a difference between the ConceptScheme object and the “whole package file”. They are the same thing. What the v1 Excel sheet currently implies is that there are actually multiple versions within version 1. If a new translation is made (and you want to publish the ConceptScheme with the updated translation), that is a change to the digital object (i.e. the ConceptScheme object) and therefore it must be a new version of the SKOS ConceptScheme.

In our example, the English version could be 1.0.0 with a publication date of 19-11-01, the Danish update is version 1.0.1 with a publication date of 2019-11-15 and the Finnish update is v1.0.2 with a publication date of 2019-12-01. This assumes that a language change is a “patch” version change, If language updates are considered to be a more significant change, then you might want to number them v1.0.0, v1.1.0 and v1.2.0. The table at https://ddialliance.org/controlled-vocabularies#policy needs to be updated so that it’s clear how major or minor an language update is.

cessda-bitbucket-importer commented 2 years ago

Original comment by Taina Jääskeläinen.

  <div class="preview-container wiki-content"><!-- loaded via ajax --></div>
  <div class="mask"></div>
</div>

cessda-bitbucket-importer commented 2 years ago

Original comment by Taina Jääskeläinen.

  <div class="preview-container wiki-content"><!-- loaded via ajax --></div>
  <div class="mask"></div>
</div>

cessda-bitbucket-importer commented 2 years ago

Original comment by Taina Jääskeläinen.

OK, the three-digit version numbers added. I attached a new version of the doc.

Sanda wanted to keep the other than source language changes to the last digit which makes sense in a way. DDI CVG versioning policy on the website will be changed eventually.

cessda-bitbucket-importer commented 2 years ago

Original comment by Joshua Tetteh Ocansey (GitHub: Joshocan).

@‌TainaFSD Should we create a separate issue for the CVs Versioning based on Carsten´s written requirements in the CVS Architecture and Design document?

‌

cessda-bitbucket-importer commented 2 years ago

Original comment by Taina Jääskeläinen.

Darren’s documents on SKOS/RDF are now available:

‌

cessda-bitbucket-importer commented 2 years ago

Original comment by Oliver Hopt.

I’m going to make a suggestion for adding the missing information within RDF export files next Thuesday on a branch. It would be great, If that could be checked and deployed soon.

cessda-bitbucket-importer commented 2 years ago

Original comment by Joshua Tetteh Ocansey (GitHub: Joshocan).

@‌Oliver Hopt Please do, we check and merge it as soon as it is committed.

cessda-bitbucket-importer commented 1 year ago

Original comment by Taina Jääskeläinen.

Just as a reminder: we need a clear schema for additional elements such as deprecation for SKOS/RDF to be added to Darren’s documents. Not sure by whom.

@‌Oliver Hopt Are you waiting for the three-digit and whole conceptScheme versioning to be implemented in the system at least in dev? The developers have been working on those. Would you be making changes to the RDF export files at that point? And would you introduce the concept-level PIDs then into RDFs? Not sure anymore what is the plan for the DDI pipeline.

cessda-bitbucket-importer commented 1 year ago

Original comment by Darren Bell.

Hi @‌TainaFSD and @‌Oliver Hopt - I am sending out an email this week to the DDI community about reviewing the new DDI CV RDF system (which also has HTML representations as well). We currently have concept-level PIDs (e.g. http://testrdf-vocabulary.ddialliance.org/cv/AnalysisUnit/2.1/d56e116 ) and the versioning is based on a 2-digit system.
We weren’t expecting or requiring a 3-digit scheme and I don’t know if it’s necessary? Once we go live with this in December, we then will have to honour our persistent versioned URIs so it won’t be desirable to then jump to a 3-digit based scheme (the third digit only seems to exist to indicate language variants, which is not relevant in DDI).

@‌Oliver Hopt Do we need a call to clearly identify what changes are in the pipeline for the CESSDA CV Manager, so that we don’t have unexpected consequences for the DDI CVs?

Thanks, Darren

cessda-bitbucket-importer commented 1 year ago

Original comment by Oliver Hopt.

Yes, a short call would be good. Maybe including Taina so that we don’t miss the content perspective. The main thing is, if any older version of the vocabularies would have the new versioning scheme applied. In that case, we should think about either waiting for the change to happen before we go productive on the DDI side or to cut of the last digit, as it will always be 0 for the SL-Version. The second approach would mean a slight change in my harvesting code but that would be done in an hour.

cessda-bitbucket-importer commented 1 year ago

Original comment by Taina Jääskeläinen.

To recap the conclusions in our call:

‌

MajaDolinar commented 1 year ago

Closing, resolved.