- From: Karima Rafes <karima.rafes@gmail.com>
- Date: Mon, 1 Apr 2019 21:25:14 +0200
- To: Andy Seaborne <andy@apache.org>
- Cc: "SPARQL 1.2 Community Group" <public-sparql-12@w3.org>
- Message-ID: <CALsrFgOyCq4jyWTuXaK5GEQbMyfktHQg9cOq9yq9VDp=XG1=BA@mail.gmail.com>
Hello I am glad to see the startup of this CG. Can I suggest to change a sentence in this template ? "The group MAY HAVE TO produce test suites to support and tools to evaluate the compliance with the Specifications." For 4 years (when I had the time), I developed a tool in order to start to test the SPARQL protocol : http://tft-reports.bordercloud.com/ The tests are now reproductible via Github and Travis CI. It's only a first step. I will be very honor, if my contribution can help your CG to accelerate the implementation of SPARQL 1.2. If the CG uses this tool, I will try to extend it to tests all communications between SPARQL services. Best regards Karima Rafes Le lun. 1 avr. 2019 à 17:08, Andy Seaborne <andy@apache.org> a écrit : > Hello everyone. > > We have a good number of participants to get started; a few people are > navigating processes and their organisations to sign up. > > How we operate is up to us, the main W3C provision is that we operate > under the "Code of Ethics and Professional Conduct". We ought to record > decisions openly and of preference use the public list. We'll > undoubtedly refine how we work as things progress. W3C do suggest a CG > charter and there is a template: > > http://w3c.github.io/cg-charter/CGCharter.html > > which seems like a good thing to fill out. > > The goal is to collect and describe SPARQL 1.2 features. I'm sure that > there will be suggestions we don't see as a simple evolution of SPARQL > 1.1 and we can collect those and label them appropriately. > > Process: > > We get to decide our processes. Here are some ideas (weakly held opinions) > > Mailing list: process and coordination. > GH issues: technical discussions > GH pages: material for a feature > Telecons: always hard to find a timeslot > > We use GH issues for technical discussions - this is easier than having > to extract discussions from email archives and makes it easier to follow > some discussions and not others. > > If an issue is leading to a feature, small or large, and someone from > the CG offers to take on the editor role for it, then a GH page (or > pages) can be started. If we have some basic template, it'll help > producing summaries later. > > Discussions around the feature can remain on issues (really, this is up > to the people involved in the feature). > > How do people feel about telecons? Start without and have them when it's > clearer how they are useful? > > Chair: > > I think we should have at least two for coverage. Some button has > already added me (and I'm willing to do it) and I'd like to suggest > Jerven Bolleman as a co-chair. > > Github repo: > > We have a github repository: https://github.com/w3c/sparql-12 > where there is a minimal place holder github page. > > https://w3c.github.io/ > > Nearby: > > The "RDF Test Curation Community Group" looks after the RDF and SPARQL > test suites, fixing mistakes and adding tests for clarification. > > https://w3c.github.io/rdf-tests/ > > The SPARQL Errata document: > > https://www.w3.org/2013/sparql-errata > > is the W3C process for recording errors in the specs. The specs > themselves don't change and there isn't a working group active with the > charter to change/update them. > > W3C Code of Ethics and Professional Conduct > https://www.w3.org/Consortium/cepc/ > > Andy > >
Received on Monday, 1 April 2019 19:25:50 UTC