W3C

RDF-star Working Group Weekly Meeting

05 October 2023

Attendees

Present
AndyS, AZ, doerthe, gkellogg, gtw, ktk, niklasl, olaf, ora, pchampin, pfps, richard-lea, Souri, Tpt
Regrets
-
Chair
Ora
Scribe
ktk, pchampin

Meeting minutes

Scribe: Gschwend, Adrian (alternate: Pellissier Tanon, Thomas)

ora: I propose to take the scribes out of the agenda.

<gkellogg> zaakim, next agendum

Approval of last week's minutes: 1

<ora> PROPOSAL: Approve last week's minutes

<gkellogg> +1

<ora> +1

<ktk> +1

<olaf> +1

<pfps> +1

<AZ> +1

<Souri> +1

<AndyS> +1

<pchampin> +0

<gtw> +1

<doerthe> +0

<niklasl> +1

RESOLUTION: Approve last week's minutes

Extended Meeting Proposal

ora: we had some discussion on the chairs meeting, we think that every so often we should have a longer meeting. On a trial base we could every other week have a two hour meeting.
… In advance we would pick the topics we want to work on. In this meeting we would not discuss bureaucratic matters.
… In the other week we would have a shorter meeting where we discuss administrative tasks only.
… I think we could make more progress and be more productive working that way. Any thoughts

?

<pfps> Fine by me.

<niklasl> +1

AndyS: We need something to bring the different strand together
… Just to check, an hour longer in the same slot? I am happy to stay an hour longer.

gkellogg: An hour earlier is not a problem for me.

gkellogg: I would prefer an hour earlier.

<Souri> Would 1.5 hrs work? Starting hour earlier is difficult for me.

pchampin: +1, good idea. But 2 hours might be quite though. I would have it rather earlier and finishing at the same time.

ktk: same for me, I would prefer an hour earlier.

olaf: Same for me.

<Tpt> +1 to 1h earlier

<Souri> I have a meeting usually starting an hour earlier (11-12noon EDT).

<AZ> +1 to 1h earlier

<AndyS> 1h earlier start is OK for me.

Souri: I have a meeting every other week at this time. If we can manage it the other week, I'm fine
… We had it this week so next week we do not have that.

ora: My proposal is to start with that next week and start one hour earlier.
… We also have to discuss if we do 90 minutes or 120 minutes. I propose 120 to progress more but I am open to that. If we do not have administrative work it might work with less as well.

gkellogg: I propose to schedule 2 hours and stop earlier if we are done.

ora: we would stop after 115 minutest latest.

gkellogg: We might want to check the W3C calendar to see if nothing else is blocking that slot.

pchampin: I don't know if I can access the combined calendar for all groups.
… I have mine with many groups but I don't see a blocker.

<gtw> I'd prefer "regular time".

ora: Should we do the current meeting also an hour earlier? The administrative one

<olaf> at this regular time

<AndyS> Neutral

Souri: That won't work for me.

ora: Got it

<niklasl> Works for me!

<Souri> Would 9-11am EDT (i.e., start 3 hrs earlier) work for people?

pchampin: I don't see any conflicts with other groups from what I can see.

<AZ> BTW, when is daylight saving time stopping in the USA?

<gtw> Both Greg(g)s.

<niklasl> (all suggested times work for me; the only blocker would be more than one hour later)

<ora> PROPOSAL: 115 min meetings every other week, 1 hr earlier than now, starting next week; shorter meetings on alternate weeks as per current schedule

<gkellogg> +1

<niklasl> +1

<pchampin> +1

<ora> +1

<ktk> +1

<Tpt> +1

<doerthe> +1

<pfps> +1

<AZ> +1

<Souri> +1

<AndyS> +1

<gtw> +0

<olaf> +1

RESOLUTION: 115 min meetings every other week, 1 hr earlier than now, starting next week; shorter meetings on alternate weeks as per current schedule

ACTION: pchampin to update WG calendar

<gb> Created action #94

ora: In order to do that productively, we need to decide in advance what we discuss. So people can do their homework.
… I think we should try to pick the topics during the short meeting. So people have time to prepare.
… In that regard we should think about the topic for next week. I do not have strong feelings.
… We can discuss on the mailing list. Unless someone has a good idea now.

pchampin: Not a candidate but I propose that we wait to the end of this meeting, maybe a topic shows up.

AndyS: The characteristics should be the things that bring us back together again as a group..
… For me currently this is what is the total scope of the working group. And moving the semantics from something which is in the Semantics TF back to the working group.

ora: I like those both.

niklasl: I am thinking the same thing. The Semantics is the one that is in my mind.
… Use cases is probably the primary thing for that. As for homework, going through the use-cases that were submitted and pfps analzyed is a good starting point. And keeping in mind what AndyS said regarding the scope.
… I posted a follow-up regarding annotation upon blank graphs on the list.

ora: this is something we could discuss next week.

niklasl: Proposal https://gist.github.com/niklasl/c22994e664663b6730613ecc1321c418

Review of open actions, available at 2

ora: pchampin you are up.

pchampin: w3c/rdf-star-wg#94 should be done
w3c/rdf-star-wg#77 is not done yet
… I did change the config file but it does not seem to show up yet.

AndyS: is it merged?

pchampin: It is not, that explains.
… I will check.

pchampin: For https://github.com/w3c/rdf-star-wg/issues/84, the core is if the last version is the very last version or the last version of this partciular version number.
… So for RDF 1.1 the latest version would be 1.1
… Some recommendations do have another header which is the last published release of *any* version of the spec.
… Another question is does the short-name point to the latest WD or to the latest recommendation.
… Some people were confused that they end up on a working draft.
… I can understand, there is no absolute standard for that. The surprise also comes from the fact that all documents use the 1.0 version of most documents.

gkellogg: In regards to the short name, RDF concepts will take you to the current draft. I believe there is a mechanism that does that. We might be fighting machinery somewhat.
… Once any spec reaches CR, then it should be considered the latest public version. WDs that do not have any weight should not go there.

<pchampin> +1 to set the threshold to CR rather than REC

gkellogg: We should come up with a policy and stick with it.

ora: What would people expect to happen when they use this should be a big consideration.

+1

ktk: I'm confused when I end up on a working draft

ktk: I am confused myself. When I look up something I am interested in real implementations. That is not the case for WDs

<pchampin> https://www.w3.org/TR/WCAG/

pchampin: I didn't make a complete check yet but I found at least one example where the short name lands on the latest version and not on the latest working draft.
… See WCAG.
… Even if it is not 100% consistent it is the least surprising way.

<niklasl> +1 short-name -> latest CR

pchampin: But agree with gkellogg, once it is a CR, it should be stable enough.

ora: So what does this mean for our open action item?

pchampin: I wanted to discuss this to be able to complete this action.
… I can draft a proposal.

<niklasl> also +1 on "what people expect" - accidentally landing in a WD may be very harmful for a "myopic" implementer...

<pchampin> draft proposal: let version-less short names point to the lastest "stable" (i.e. CR, PR or REC) version of the spec

ora: Anybody disagree with this?

ora: We can proceed like this.

ora: For https://github.com/w3c/rdf-star-wg/issues/19, AZ you worded a new proposal.

AZ: I summarized it here w3c/rdf-star-wg#19 (comment)
… I hope this catched all the comments we had.
… And that they are not too controversial.
… First it says we want to have a profile that excludes quoted triples.
… The second says it should be named "RDF 1.2 basic"
… The third one says it only excludes quoted triples but not other enhancements of RDF 1.2

<pchampin> +1 on all 3 proposal

<AndyS> s/quited/quoted/

AZ: Can we vote on these proposals?

ora: We can.

<ora> PROPOSAL: Adopt all 3 proposal from AZ

<gkellogg> +1

<ktk> +1

<ora> +1

<Souri> +1

<pchampin> +1

<AndyS> +1

<pfps> +1

<AZ> +1

<olaf> +1

<doerthe> +1

<niklasl> +0.9 (ideally there wouldn't be something more than "basic")

<Tpt> +1

ora: What do you mean with that niklasl

niklasl: It has to do with the semantics. Ideally it would not require different profiles.

RESOLUTION: Adopt all 3 proposal from AZ

ora: thank you AZ for your work on this

ora: we can close the action item now.

Review of pull requests, available at 3

ora: We have a few editorial ones.
… Which I believe have been on the list for some time.

olaf: w3c/sparql-query#124 is still discussed, we leave it open.

<Souri> I get 404 when accessing https://github.com/orgs/w3c/projects/20/views/4 ... did I miss some setup steps?

ora: w3c/sparql-protocol#22 and w3c/rdf-turtle#46 are ready to merge.

Souri: are you logged in on github?

gkellogg: I made some updates on w3c/rdf-concepts#66

<Souri> No. Could you point me to the steps for github login?

gkellogg: see my comment here w3c/rdf-concepts#66 (comment)

Souri: it looks like you simply need to be logged in with your github user to access this one.

pfps: I'm getting more confused. gkellogg says it's a change to the value space. but I-JSON is to the lexical space.

gkellogg: It is two different things.
… It is the lexical space with restrictions.

pfps: It is different to the lexical space.

gkellogg: I am happy to discuss the wording.

<Zakim> pchampin, you wanted to argue that namespaces are precisely there to allow this kind of restriction

pchampin: playing the devil advocate. pfps you say it's json, we say it's RDF:JSON. that's what namespaces are for.

niklasl: I would like to second that. The imperoperability thing is what we are after here.
… we do not want to hurt parsers unexpectedly. JSON has been underspecified.

pfps: I stay in my rationale. There is a perfectly good syntax for JSON. RDF should adhere to that.
… there is an agreed on way to process this larger grammer.

gkellogg: The RFC says there is not a clear way to handle some things.

pfps: that's my other complain about using I-JSON as lexical space. I do not believe that there is a definition of which JSON texts are I-JSON texts.

ora: let's continue on the mailing list.

AndyS: The chairs should decide.

ktk: We will discuss and send out by Friday.

pchampin: looks quite good

Summary of action items

  1. pchampin to update WG calendar

Summary of resolutions

  1. Approve last week's minutes
  2. 115 min meetings every other week, 1 hr earlier than now, starting next week; shorter meetings on alternate weeks as per current schedule
  3. Adopt all 3 proposal from AZ
Minutes manually created (not a transcript), formatted by scribe.perl version 222 (Sat Jul 22 21:57:07 2023 UTC).

Diagnostics

Succeeded: s/quited/quoted/

Failed: s/quited/quoted/

Succeeded: s/htis/this/

Succeeded: s/Fridsay/Friday/

All speakers: AndyS, AZ, gkellogg, ktk, niklasl, olaf, ora, pchampin, pfps, Souri

Active on IRC: AndyS, AZ, doerthe, gkellogg, gtw, ktk, niklasl, olaf, ora, pchampin, pfps, richard-lea, Souri, Tpt