PR to refine the message about dataset series' member (issue 1429) #1458
Conversation
…dcat:inSeries's usage note
… dcat:DatasetSeries
… of dataset series
riccardoAlbertoni
requested review from
dr-shorthair,
pwin,
agbeltran,
andrea-perego and
davebrowning
riccardoAlbertoni
added this to In progress
in DCAT Sprint: Dataset Series
via automation
dcat/index.html
Outdated
| @@ -2495,7 +2495,7 @@ <h4>Property: in series</h4> | |||
| <!--tr><th class="prop">Inverse property of:</th> | |||
| <td><a href="#Property:dataset_series_series_member"><code>dcat:seriesMember</code></a></td> | |||
| </tr--> | |||
| <tr><th class="prop">Usage note:</th><td> Normally, child datasets in dataset series are represented as <code>dcat:Dataset</code>. The use of <code>dcat:Distribution</code> for typing child datasets is however recognized as a possible alternative, whenever it addresses more effectively the requirements of a given application scenario.</td></tr> | |||
| <tr><th class="prop">Usage note:</th><td> Child datasets in dataset series SHOULD be represented as <code>dcat:Dataset</code>.<!--The use of <code>dcat:Distribution</code> for typing child datasets is however recognized as a possible alternative, whenever it addresses more effectively the requirements of a given application scenario.--></td></tr> | |||
There was a problem hiding this comment.
This is quite a strong change. It is clearly justified in principle. However, it may not be sustainable in practice. DCAT does not have wide adoption already. Maybe it is more influential than adopted.
There was a problem hiding this comment.
This is quite a strong change.
It might be not that strong. We are using "SHOULD", not "MUST".
"SHOULD" means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
The change attempts to clarify that using datasets as members in series is the recommended solution.
Other solutions are possible, but this is the one DCAT 3 considers the most flexible and versatile and the one recommended for the new implementations.
Existing or even future implementations can do otherwise if they have thoroughly considered the consequences.
We don't want to alienate the existing implementations. Therefore, we explained that current solutions are not incompatible with DCAT 3 during the upgrade to DCAT 3 (see the non-normative section beginning at line 5128).
However, unless we want to support more than a solution and thus accept interoperability issues intrinsic in the availability of more than one recommended solution, we need to be clear on the recommended approach.
I am not 100% sure this is the best way to do it.
Do you think a "MAY" instead of "SHOULD" would be more appropriate? Do you have any suggestions on how to convey the message more appropriately?
There was a problem hiding this comment.
Thanks Riccardo. I'm OK with the proposal. Was just checking, and I note the use of SHOULD.
|
Though I guess there will be further discussion and request of adjustments for this PR, I am marking this as ready for review to solicit opinions ;) |
|
@andrea-perego, please double-check if I have implemented your suggestion correctly via 62945d9, |
Co-authored-by: Andrea Perego <andrea-perego@users.noreply.github.com>
Co-authored-by: Andrea Perego <andrea-perego@users.noreply.github.com>
Co-authored-by: Andrea Perego <andrea-perego@users.noreply.github.com>
Co-authored-by: Andrea Perego <andrea-perego@users.noreply.github.com>
riccardoAlbertoni
changed the title
Co-authored-by: Riccardo Albertoni <albertoni@ge.imati.cnr.it>
Co-authored-by: Riccardo Albertoni <albertoni@ge.imati.cnr.it>
This PR is a work in progress attempt aiming at sharpen the message about dataset series members.
Rendered at: http://raw.githack.com/w3c/dxwg/dcat-issue-1429/dcat/index.html
Diff at: https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fw3c.github.io%2Fdxwg%2Fdcat&doc2=https%3A%2F%2Fraw.githack.com%2Fw3c%2Fdxwg%2Fdcat-issue-1429%2Fdcat%2F
This when merged is expected to close #1429.