search

w3c / rdf-star

RDF-star specification
https://w3c.github.io/rdf-star/
Other
118 stars 23 forks source link

find out what are the limits of "new features" in the new W3C process #195

Closed pchampin closed 2 years ago

pchampin commented 3 years ago

This was discussed during today's call: https://w3c.github.io/rdf-star/Minutes/2021-07-16.html#a01

ericprud commented 2 years ago

Are y'all interested in the "evergreen" process? If so, it's basically that you have a bit more work to do on patent commitments before CR (iirc), but you can then cycle for years in CR and use that as your evergreen spec.

afs commented 2 years ago

Personal comments.

The charter https://github.com/w3c/rdf-star-wg-charter/ is not for a wholesale update of RDF. It is specific to RDF-star, and could also deal with some errata processing because the documents are "open". The old-style WG's ended when their REC's got published. There was no opportunity to alter documents even for minor matters.

As a community, we have been quite diligent and we have:

but it would be better to fix documents.

I also hope any new WG can exit to a maintenance mode where errata can be dealt with within the bounds of mistakes and clarifications.

As to "evergreen" (and sometimes an errata is a visible fix - it happens), new features for a data format used to publish data long-term are hard to deal with. Changing something that isn't tied to syntax extension could mean a change in meaning without a change in appearance.

Even though RDF-star is new syntax, I don't think it would have been appropriate for an "evergreen" new feature.

It is possible to imagine new features where there is a syntax (SPARQL and some extent, SHACL and ShEx) and new features can be ignored in the sender and the receiver can reject a request. But it's not simple. It must be done within well-understood limits on "new features".

gkellogg commented 2 years ago

For my part, I'm concerned that creating such a narrow focus will help miss a rare opportunity to do some seriously needed updates to the related specs, and prevent a mechanism to maintain them into the future. Sure, having a narrow focus for the charter will help its chances at approval, and widening the charter, particularly with evergreen options, leaves open the possibility of allowing too much change. But, there is normative maintenance that needs to occur.

Perhaps there is some wording that would focus the WG on RDF-star, specifically, and then create a class of updates that a longer-term maintenance group could continue to address beyond the strictly narrow RDF-star work, but not allowing things other than simple extensions and corrections.

Ultimately, the community of interested vendors, researchers, and developers should collectively decide the future of RDF, and having a chartered group to allow them to pursue this should be a good thing. Otherwise, it will be the 2030's before there's an opportunity to re-align SPARQL with RDF 1.1, extend SHACL to RDF-star (and named graphs), address I18N issues started in JSON-LD, address SPARQL 1.2, EXISTS, and full-text issues, among others.

pchampin commented 2 years ago

This was discussed during today's call: https://w3c.github.io/rdf-star/Minutes/2021-09-03.html#x052