– DRAFT –
RDF-star WG

organization of the WG

<gkellogg> https://dvcs.w3.org/hg/rdf/summary

gkellogg: re. selection of editors, there are also mechanical bits to setup
… there are many specifications, present on Mercurial (link above)

ora: what do we need to do to create some kind of editor's draft?

pchampin: the charter says we are going to publisg several recommendations

<Zakim> gkellogg, you wanted to suggest we really need to update the RDF specs that are out there.

pchampin: but we can decide to change this.
… They are mapped on the RDF 1.1 and SPARQL 1.1 specs, so it make sense.
… Also the CG report is built as a "patch" of those existing specifications.

gkellogg: it makes sense to keep the recommentations -- if someone mentions the Turtle spec, it has to still be there

ora: how do we proceed to create a new version of each spec?
… do they all have to go through the heavy process of being updated?

csarven: I don't think that al the specs will eventually need a next version.
… Having 2 editors min per spec is a way to keep the work running, in my experience.
… As for the release, any version that we have right now could be turned into an editor's draft.
… The FIrst Public Working Draft is not expected to be already mature.
… This is just the version that we are starting with.

TallTed: unfortunately, I think that all the documents need to be updated as a batch.
… SPARQL 1.1 is aligned with RDF 1.0, and there are similar disconnections in the stack of documents.
… This is causing problems in the real world.
… We have the power to fix this, we should.
… It might need that we call them 2.0 rather than 1.2, as there will be breaking changes.

pchampin: +1 to csarven and TallTed

ora: I'm not opposed to that, but my worry is that there will be demands to update other parts of these documents, that are not related to RDF-star.

<TallTed> I think that pandora's box is already open, and pretending that it's opened at the back (where we can't see) will do no-one any favors in the end.

ktk: what would be the "RDF-star spec" once we update all the other ones?

olaf: back to what csarven said earlier: I don't think it is as easy to start with the existing specs,
… because they are not using ReSpec, and we probably want to start with ReSpec documents.

<csarven> I meant content-wise not formatting.

gkellogg: I believe they are in ReSpec, but a very old form of ReSpec.
… We could automate the process.
… Re 2.0 vs 1.2, I'm not aware of any breaking changes that the CG report introduces.
… We will also need to include errata, one of them is important for the RCH WG (about canonical N-Quads).
… Re the pressure to do new things: that would require us to update the charter.
… We might accept to do that once the RDF-star part is ready, but not before.

<Zakim> gtw, you wanted to note that the charter says we'll roll editorial errata into the new specs.

gtw: agree with TallTed: once we are at updating the specs, we need to fix those inconsistencies
… It's important to find alignment in these specs as we are touching them.

<gtw> gtw: some of that alignment falls under the charter item regarding addressing errata

ora: I like how the SPARQL spec and others are organized: overview, then a list of different specs

<gkellogg> +1 to an overview document, and specs should probably refer to each other, as SPARQL does.

ora: We should break up what lies ahed into parts;
… then we may find out along the way that some of those parts are actually revisions of an existing spec

csarven: my point about editors drafts was about the content, not the formatting

<csarven> https://www.w3.org/pubrules/doc

csarven: I believe that the editors drafts can be anything, even markdown.
… The FPWD must abide by pubrules (link avove)
… If the old spec use an old version of ReSpec, if it passes the rules, then that would be OK.
… We are not even forced to use ReSpec, what matters is passing the pubrules.

ora: are there objections about using ReSpec?

gkellogg: I have a lot of experience with ReSpec
… I can't see the files or mercurial, but my memory is that they are in the ReSpec format already.
… It makes easy to validate the rules.
… Also, a tool called PR-review is able to format a preview and a "diff" for every PR.

<olaf> Gregg, only for one doc per repo?

<Zakim> csarven, you wanted to mention formatting and editorial preference considerations

<gkellogg> Yes, one doc per repo. So, an rdf-concepts repo, for example.

<olaf> I see. Thx for the clarification.

csarven: in the Solid CG, the editors of each spec decide which tooling they want to use
… OTOH If you want different contributors to jump in easily, picking one tool for all the specs is helping.

<csarven> http://www.w3.org/ns/spec

<csarven> https://solidproject.org/TR/protocol

<csarven> https://solidproject.org/ED/protocol

csarven: those are examples of Solid specs annotated as RDFa with the 'spec' ontology
… each normative requirement has its own IRI, and a machine readable description
… This is relatively new, not used in ReSpec and Bikeshed right now.
… These annotation do not interfere with pubrules.

<csarven> https://solid-contrib.github.io/specification-tests/coverage

csarven: They can be useful for describing test cases.

<gkellogg> There are also respec tags for identifying tests associated with some normative statement.

ora: trying to understand the spectrum of possiblity: we can use ReSpec together with those annotations?

csarven: yes

ora: I like the idea of these new tools, but I would suggest that we use one tool for all specs, and pick ReSpec.

<gkellogg> +1 to picking one tool, and if docs are already in ReSpec, we should use that.

pchampin: I can create a first "spec" repo

gkellogg: the naming convention is usually to use the short-name of the spec as the name of the repo
… I can be part of the effort to migrate the existing specs

<Souri> I think two specs are definitely going to be needed. So, IMHO, we may want to consider starting with two specs: RDF-star and SPARQL-star.

gkellogg: but that will need more people

ACTION: pchampin to create a firsr "spec" repo

<ghurlbot> Created action 52 create a firsr "spec" repo (on ) due 8 Dec 2022

ACTION: everybody to reflect on what they think is missing in the CG report

<ghurlbot> Created action 53 reflect on what they think is missing in the CG report (on ) due 8 Dec 2022

<gkellogg> maybe create an issue for this that people can chime in on.

scheduling

ora: I realized that once a month, I will have a conflict with this timeslot
… this is not the end of the world, but if other people may want to change?

TallTed: this timeslot is fine for me in general.
… if we are going to look for something else, I suggest we use a Doodle poll of some kind.
… Email discussions on this kind of questions go on forever.

gkellogg: I think we had a doodle pool, and this was the slot that came up.
… Personally I could make do 1 or 2h later, but that's ok.

<Souri> The current schedule works perfectly for me (lunch time in US EST), but I can adjust if needed.

<TallTed> I'll have frequent though inconsistent conflicts if we move 1 or 2 hours earlier on Thursdays

pchampin: the doodle that we had was for the kick-off. Maybe it was convenient for some people that day, but not on a regular basis

ACTION: ktk to set up the doodle for the recurring time

<ghurlbot> Created action 54 set up the doodle for the recurring time (on ) due 8 Dec 2022

csarven: being based in Europe, this slot is ok for me because it does not conflict with my other meetings

ora: let's keep this time slot until the doodle pool gives its result
… ideally, we can send it during the week, and discuss it next Thursday
… I anticipate that as the group progresses, we might divide in task forces,
… and the whole group will not need to meet every week.

<Souri> exit