Any other properties to mention in class dcat:DatasetSeries?

[riccardoAlbertoni]

Should we add adms:next, adms:prev in the dcat:DatasetSeries class description?

Should we include in the dcat:DatasetSeries class description the properties whose values are involved in dataset series inheritance (e.g. dct:issued,dct:spatial)?
The expected constraints can be explained in their usage notes...

[andrea-perego]

@riccardoAlbertoni asked:

Should we add adms:next, adms:prev in the dcat:DatasetSeries class description?

I think they should be placed under dcat:Resource.

Should we include in the dcat:DatasetSeries class description the properties whose values are involved in dataset series inheritance (e.g. dct:issued,dct:spatial)?
The expected constraints can be explained in their usage notes...

I think this is an overall issue, not limited to dataset series. We have a number of properties under dcat:Resource whose use with some subclasses should be explained (e.g., the use of dct:spatial in dcat:DataService).

About replicating the property definition, an alternative option is to include such explanation either in the usage note of the property under dcat:Resource. Otherwise, we can add it in the section devoted to the specific class, right after the list of inherited properties.

[riannella]

Will dcat:DatasetSeries be a subclass of dcat:Catalog ?

[dr-shorthair]

or of dcat:Dataset ...

[makxdekkers]

Wouldn't it be confusing for dcat:DatasetSeries to be a subclass of dcat:Catalog -- which is itself a subclass of dcat:Dataset. What would be the advantage? Is it not enough for dcat:DatasetSeries to be a direct subclass of dcat:Resource without the intermediate subclass relations?

[dr-shorthair]

DataSeries is much more like a dataset that it is like a service (or a specimen or an instrument or any other kind of thing that you might model as a subclass of dcat:Resource). IMAO it absolutely belongs in the dataset/catalog branch of the resource tree. I think we are just exploring whether a series is conceptually merely a list of members (and therefore like a catalog) or is a conceptually unitary thing (and therefore like a dataset).

[riannella]

Here is the draft model we are currently working on to give some context for our use cases...

[dr-shorthair]

This model shows a Dataset Series as a member of a catalog. This is consistent with it being a kind of Dataset.

Then the relationship between Dataset Series and its Datasets is consistent with what was foreseen in DCAT v2 in the discussion of relationships and qualified relationships. I would expect something like dcat:hasSeriesMember / dcat:inSeries could be modeled as specializations of the more generic dcterms:hasPart / dcterms:isPartOf to manage this case.
See #1307 (comment)

[andrea-perego]

Coming back to the original topic of this issue:

I've created a PR (#1340) to add adms:last, adms:next, adms:prev to dcat:Resource.

After having done that, I wonder whether we should define these properties in the DCAT namespace.

The reason is as follows:

adms:last, adms:next, and adms:prev are defined in ADMS as subproperties of xhv:last, xhv:next, and xhv:prev, which are specifically meant to relate resources that are part of an ordered collection. E.g., the definition of xhv:prev is:

prev refers to a previous resource (before the current one) in an ordered collection of resources.

As a side note, these xhv properties basically correspond to those defined in the IANA Link Relations register (last, next, prev), and used both in HTTP Link headers and in HTML LINK elements.

This makes adms:last, adms:next, and adms:prev fit for being used to relate resources in a dataset series.

However, their textual description mentions explicitly the notion of version, which we are considering as distinct from the notion of series, and described by using dedicated properties (e.g., dcat:previousVersion). E.g., the definition of adms:prev is:

A link to the previous version of the Asset.

Because of this, it is maybe preferable to define dcat:last, dcat:next, and dcat:prev, to avoid any confusion about the actual use of these properties in DCAT.

WDYT?

[riannella]

If the definitions mention versions then they are not appropriate for these cases - so define our own is ok
If we have "last" should we have "first" ?

[andrea-perego]

@riannella said:

If the definitions mention versions then they are not appropriate for these cases - so define our own is ok
If we have "last" should we have "first" ?

Fair enough. BTW, as prev, next, and last, also the "first" relationship is defined in [XHTML-VOCAB] and in the IANA Link Relations register.

The question is what we need for dataset series. Are prev/next enough? Or we also need first/last?

[rob-metalinkage]

Do you really want to pull in terms into DCAT as a W3C Rec from a W3C Note that itself declares it is a profile of DCAT?

Understand you need to use these, and not want to re-invent the wheel (and my own implementations do exactly the same) - but the logically consistent approach would be to define a profile of DCAT that uses the parts of ADMS you need, as a profile of ADMS itself probably, that itself has the same status (Note) of ADMS. You then guide people to this rather than add it to the normative Rec status DCAT specification. It appears that a decision about not publishing profiles of DCAT is becoming an arbitrary limitation that leads to anti-patterns where profiling would provide a better option.

[rob-metalinkage]

@andrea-perego +1 to adding these to DCAT namespace if you can agree on using exact same, or broader, semantics as the ADMS profile - the ADMS properties can then be declared subProperties of DCAT in either an update or an alignment module. (IMHO it would be good to update and refactor ADMS into a series of modules that address different aspects and formally declare it a profile of DCAT - happy to help with that as I need some subset)

[andrea-perego]

@rob-metalinkage ,

Actually, I would propose we define dcat:prev, dcat:next, etc. with no reference at all to adms:prev, adms:next, etc. - i.e., they shouldn't be either equivalent properties or subproperties of the ADMS ones, and I would not even use SKOS semantic relations. The reason being to avoid any misunderstanding on the semantics of these DCAT properties, which are not at all about "versions" (whereas, as said above, this notion is explicitly included in the textual definition of the ADMS ones).

On the other hand, I think it might be worth making them subproperties of xhv:prev, xhv:next, etc. to make the link with the corresponding IANA Link Relations.

[riannella]

Question: next and prev can only really be used between datasets in a dataset series?

@riccardoAlbertoni What was your original use case?

[andrea-perego]

@riannella said:

Question: next and prev can only really be used between datasets in a dataset series?

Not necessarily (this is why they are under dcat:Resource). But dataset series is the only use case we have at the moment.

[andrea-perego]

Based on the discussion on this thread, and since no objection to the proposal in #1308 (comment) , I would consider it as approved.

PR #1340 has been updated accordingly, by adding properties dcat:prev, dcat:next, dcat:last, and dcat:first to dcat:Resource.

The PR is now under review by the DCAT editors.

[agreiner]

Hm, it just occurred to me that next/previous has the same issue for developers as we encountered with membership in a series, that developers won't know in advance which one is being used to hold the chain together and so would have to test for both in code. Also, assigning next when a dataset is first published seems like a stretch, so we again run into the problem of updating the metadata after the fact. Yet, having next when it's available would certainly be useful. I sort of want to make previous required but both encouraged, or say you can't use next without also using previous.

[andrea-perego]

Hm, it just occurred to me that next/previous has the same issue for developers as we encountered with membership in a series, that developers won't know in advance which one is being used to hold the chain together and so would have to test for both in code. Also, assigning next when a dataset is first published seems like a stretch, so we again run into the problem of updating the metadata after the fact. Yet, having next when it's available would certainly be useful. I sort of want to make previous required but both encouraged, or say you can't use next without also using previous.

Thanks for the heads-up, @agreiner .

As #1335, I think this relates to the more general discussion on the possible approach to be used in DCAT to define inverse properties - see #1336

I'll create a separate issue to keep track of it, and link to it from the ED.

[andrea-perego]

Hm, it just occurred to me that next/previous has the same issue for developers as we encountered with membership in a series, that developers won't know in advance which one is being used to hold the chain together and so would have to test for both in code. Also, assigning next when a dataset is first published seems like a stretch, so we again run into the problem of updating the metadata after the fact. Yet, having next when it's available would certainly be useful. I sort of want to make previous required but both encouraged, or say you can't use next without also using previous.

Thanks for the heads-up, @agreiner .

As #1335, I think this relates to the more general discussion on the possible approach to be used in DCAT to define inverse properties - see #1336

I'll create a separate issue to keep track of it, and link to it from the ED.

Done - see issue #1346 and PR #1345 (8ce4db2)