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

My understanding of W3C's process is that we take the best guess of the working group and publish that for input from the community, not that we take what feels the most inclusive and put that forth. By typing +1 in a meeting to publish, one says in effect that they are supportive of the text as it stands and okay with the assumption by the rest of the world that you stand by it. Notes can be helpful for expressing alternatives, so I would expect additional options be shown in notes, thereby remaining inclusive of a minority opinion if there isn’t agreement in the group. The current note, to me, doesn’t clearly state the concern raised at all. I’d prefer to have a note that says some members of the group feel there should be an inverse to inSeries and ask if anyone feels it is important to do so. Given the strong reason not to do so, I think this approach is justified.

Re update dates, I think any property that assumes people will make updates to a published dataset’s metadata is flawed. Even the most diligent publishers of data will never be able to update copies of datasets that find their way to secondary sites and to users. Update dates only make sense to me when they reflect the state when the dataset (or series) was published.

-Annette

> On Mar 17, 2021, at 6:36 PM, Riccardo Albertoni via GitHub <sysbot+gh@w3.org> wrote:
> 
>> 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 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)
> 
> 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 https://github.com/w3c/dxwg/issues/1307#issuecomment-801550988 using your GitHub account
> 
> 
> -- 
> Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
>

Received on Sunday, 21 March 2021 00:22:48 UTC