Do we need a new property (let's name it dcat:seriesMember) defined as dcat:inSeries's inverse?

Requests for dcat:inSeries's inverse to connect the dataset series to its children have been discussed in issue #1307.

Part of the previous discussion is reported below.

Originally posted by @riannella in #1307 (comment)

In our sector, for example, a Regulator would say the more important relationship was from the series to the parts.
Let's have both.

Most of the concerns against adding this property elaborate on maintaining metadata consistent when a dataset is added to the series.

Originally posted by @jakubklimek in #1307 (comment)

@dr-shorthair @riannella From the point of view of an application developer, let me again state that I would strongly prefer to standardize only one of the two mutually inverse properties.
Otherwise, compliant applications and queries need to always account for the possibility that in one data catalog, the datasets are connected to the series using one property, in another using the second, which makes them more complex with each inverse property pair.

Originally posted by @agreiner in #1307 (comment)

I would suggest keeping only the inSeries property so that one needn't worry about updating metadata for the series every time a new dataset is added to that series.

Keeping the metadata of series consistent while adding new datasets seems to be required anyway by the assumption of "upstream inheritance" discussed in #1273

Originally posted by @riccardoAlbertoni in #1307 (comment)

I suspect the metadata of the dataset series needs to be updated anyway. Especially if we keep the upstream inheritance explained in https://raw.githack.com/w3c/dxwg/dcat-dataseries-issue1272/dcat/index.html#dataset-series where it is said: "The update date (dcterms:modified) of the dataset series should correspond to the latest publication or update date of the child datasets."
Also, we are having some parallel discussion of whether supporting inverse properties with a "lightweight approach" adopted by PROV-O (https://www.w3.org/TR/prov-o/#inverse-names) ( we have discussed this in tonight call, see meeting minutes)