Open iherman opened 7 years ago
As a background: one of the biggest problems (in my view) is that there has never been a JavaScript implementation of and RDF environment generally accepted and used by the community (although there are some libraries around, but none seem to be accepted as THE JS environment for RDF). This has certainly been one of the (but not the only) reasons why RDF never made it in the Web App developers' world.
It is worth keeping an eye on that...
See also thread on https://lists.w3.org/Archives/Team/team-strat/2018Jun/0014.html:
The community group has not been very active recently. One possible interpretation is that their specifications (https://rdf.js.org/) are considered stable enough. @bergos @rubensworks would you confirm that interpretation? If so, would it make sense to
The core specs (https://rdf.js.org/data-model-spec/ and https://rdf.js.org/stream-spec/) are indeed quite stable, and are being implemented by most RDF-related JS/TS libraries.
The dataset spec still contains some experimental features, so that's not very stable yet AFAIK (but @bergos may have a better view on that). The group is also still actively working on new specs, such as the query spec.
Most of the discussions in this group happen within the issue trackers on https://github.com/rdfjs/.
publish them as final reports so that they appear as such on the CG page?
I'm not a chair of this group, but @bergos and @RubenVerborgh are, so I assume they can follow up on that.
try to move things forward to REC-track?
Definitely interested in this (at least for the core specs). Would this involve setting up a new WG?
publish them as final reports so that they appear as such on the CG page?
It would be a good idea to publish a report. In which context should the final be interpreted? The work of the group will continue. The current specifications are stable, but there can be new ones, and some may be extended.
The dataset spec still contains some experimental features, so that's not very stable yet AFAIK (but @bergos may have a better view on that).
That's correct. I opened an issue to discuss removing the experimental interfaces from the published specification and continue working on the experimental features in a separate branch.
All three specifications have some errors in the WebIDL, which should be fixed. Apart from that, the specifications are final from my point of view.
try to move things forward to REC-track?
Definitely interested in this (at least for the core specs). Would this involve setting up a new WG?
I'm also interested and would like to know what needs to be done to go in that direction.
@bergos @rubensworks
1) About the CG final report
"final" does not mean that the CG may not continue improve the report, or even publish another "final report" later. "final report" differs from draft report in that
2) About moving to REC-track
The first thing is to check that there is enough support in the community, as the charter of the Working Group will eventually have to be approved by the Advisory Committee. In other words, will there be enough interested W3C members to participate to the WG.
Notice that the REC-track is not meant to simply rubber stamp the work of the CG. The WG might decide to make significant changes to the specification before publishing them.
Thanks for the details @pchampin.
@bergos perhaps this might be a good time to schedule another RDF/JS CG call to discuss next steps? (happy to follow up on this myself, but looking at you first since you're a CG chair)
It seems that the RDFJS Community Group is more active than I thought; there are some initial specs for RDFJS. This may at some point come back to us, depending on what priority we want to give to this.