-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RDF JS #102
Comments
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). Most of the discussions in this group happen within the issue trackers on https://github.com/rdfjs/.
I'm not a chair of this group, but @bergos and @RubenVerborgh are, so I assume they can follow up on that.
Definitely interested in this (at least for the core specs). Would this involve setting up a new WG? |
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.
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.
I'm also interested and would like to know what needs to be done to go in that direction. |
"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
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. |
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.
The text was updated successfully, but these errors were encountered: