Re: [dxwg] Should we specialize dcterms:hasPart for dcat:DatasetSeries? (#1307)

> Hm, I'm getting a little concerned about the direction here. This thread shows at least three people who agreed that it would be beneficial to only define the inSeries property and leave out hasSeriesMember or whatever, because it makes it difficult to determine membership in a series programmatically, since one doesn't know in advance which approach is taken in the metadata. Yet we have people saying they see no reason not to include both, the draft includes both, and there is ongoing discussion of what to call the second term. Next, I expect someone will say that we should just go with it this way and see if anyone outside the group comments, nobody will comment, and we will be stuck with something that doesn't reflect what most of us want, or at least a process that doesn't address the issue raised.

Thanks for your comment, @agreiner.  I understand your concern. 

As for your previous specific 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.

I suspect the metadata of the dataset series needs to be updated anyway. Especially if we keep the upstream inheritance explained in  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 ( ( we have discussed this in tonight call, see meeting minutes)

 I think the difficulty here is that there are different intertwined aspects for deciding whether or not to have both inSeries and hasSeriesMember, and which one of the two.  
In the PR I am co-drafting, I have kept both the directions as I sensed the discussion was still open, and there were views in contrast. I might have "miscounted" the commenter positions as the discussion is quite intricated, and people seem to have changed mind during the discussion. Also, some editors and contributors haven't expressed their views.  For these reasons, I attempted to be "inclusive" and have a draft on which we can reconsider this point starting from a more stable description.   


GitHub Notification of comment by riccardoAlbertoni
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Thursday, 18 March 2021 01:36:43 UTC