Meeting minutes
TIL -- There's a list of all previous meetings : https://
someone ought invent a standard for for news feed on the web.
<ktk> additional items proposed for agenda:
<ktk> * GH Project for collecting issues [1]
<ktk> * Suri: Slide on storage, performance, and future-proofing aspects related to multi-edge handling (5m)
<ktk> * Gregg: Editor assignments
<ktk> https://
ktk: accept the minutes
… feedback on agenda
… GH repos
… a GH repo for issues of all docs
… Souri would like a 5 min slot
… gkellogg asked about editors
pchampin: created a GH repo per specification
… github pages active
… 'main' protected
<ktk> AndyS: What is published to GH pages, is it the whole repo or a particular subdirectory?
<ktk> pchampin: it's the whole repo
pfps: Q about how GH page work
… respec can run locally?
<ktk> AndyS: yes it can be run locally, it's some javascript in the spec itself
<ktk> pfps: can we have pre-commits for checking things on commits?
<ktk> AndyS: there are some pre-commit hooks but they only check basic things, not respec related
pfps: will dig into checking possibilites for reSpec.
<ktk> AndyS: I haven't pushed any content on SPARQL stuff yet, I was working separately.
<ktk> ... I got some respec errors and will push after that.
Issues project
ktk: Idea is a GH project for organising work.
… also issues across repos
<pchampin> w3c already uses GH projects, so it should be possible
ktk: one central place to see all work
pfps: New feature of sub-projects may be useful
… "task lists"
… in an issue link to sub issues
<Zakim> TallTed, you wanted to ask how GitHub projects handle GitHub notifications
TallTed: GH creates features that are not fully thought out.
… how does GH handle notifications?
ktk: subscribe is per project
… should be cautious in using the features
ktk: PA and chairs will come back with a proposal.
Editor assignments
ktk: gregg gave a list of docs he's interested in.
<TallTed> +1 handle Editor assignments in an issue. Possibly with checklist of docs at top, to be supplemented with Editors as volunteered/assigned.
<ktk> AndyS: I assume we do not do a complete review-cycle since the 1.1 specs
<ktk> TallTed: I think most changes would be between 1.1 and today. but it would be good if reviewers still have a look at the whole document.
<ktk> TallTed: Errata in a previous edition should be corrected in a new addition
<ktk> ... if we find an error in a previous edition it should be corrected in any way.
<ktk> AndyS: it depends on how much work this creates. we have only 18 months of time
<ktk> TallTed: if errors create work, we should be able to extend the timeframe
<ktk> pfps: if we get a comment that creates massive changes for everything, we can say it is out of scope.
pfps: we have the option of declining comments
<ktk> TallTed: if the need for change is valid, like they discover a broken thing in the current spec, it should be treated with respect.
ktk: Will create issue to record editor offers
ACTION: ktk, to create an issue for editors offers
ACTION: ktk to create an issue for editors offers
<ghurlbot> Created action 11
souri: present slide
The scribe asks that the slide be sent to the WG email list.
<pfps> I'm confused. What is supposed to be happening here? An example that is part of a worked-out use case seems indicated.
timestamp
<pfps> timestamp is the use case? How is this being represented?
I'm confused.
pfps: This depends on what is presented and how. What's the UC?
… the WG should pay attention to use cases
… provenance, modal logic. Can't future proof everything.
<pfps> This looks like an attempt to change the RDF semantics from set-based to bag-based. This is a fundamental change.
TallTed: slide implies an automatic id - which is not always the case.
<AZ> There's existing work (quite a lot actually) about mapping relational data to RDF (and back). It works. Do we need a new RDF that mimmics relational data so much that it's essentially doing the same thing?
TallTed: I think you are asking for implicit and explicit naming
… need to explain the slides
<TallTed> +1 to explicit use case (which I don't have ... yet)
<AZ> +1 for concrete use cases
<pfps> I agree that introducing things via email is better.