Meeting minutes
Approval of last week’s minutes: 1
<pfps> minutes look acceptable
<ktk> PROPOSAL: Approve last week's minutes
<TallTed> +1
<Dominik_T> +1
<olaf> +1
<AndyS> +1
<enrico> +1
<ktk> +1
<niklasl> +1
<pchampin> +1
<gtw> +1
<pfps> +1
<tl> +1
<william-vw> +1
<Souri> +1
<fsasaki> +0
RESOLUTION: Approve last week's minutes
RDF Threat Model: get some help from the TMCG 2
pchampin: the security IG work on a thread model for RDF
<pchampin> w3c/
pchampin: community group (not IG)
… there will be a call about that
… the dates/times are in the calendar of the CG
… interested people are encouraged to join this call
<TallTed> fwiw, I would join the June call, but cannot join the May call
pchampin: the idea will be that we come with our diagram
<pchampin> https://
pchampin: and they will guide us in the right direction regarding thread modeling
ktk: preferences for these times?
AndyS: I can do both, but would like time to prepare
ktk: I will join as well.
pchampin: Okay, I will ask them for the date in June.
… If they cannot, then I will ask for the date in May.
… I would like to do this rather sooner than later because it may be a blocking issue for CR
Report from the meeting with the TAG
pchampin: I will ping the relevant folks here in the github issue to be created for that call
pchampin: We had a meeting with the TAG about the updated syntaxes breaking old parsers
… The conclusion was that the TAG is okay with us moving forward if ...
… we provide more guidance what parsers have to do when encountering something that they don't understand
… and what RDF 1.1 clients should do when they encounter 1.2 data
AndyS: meeting went well, they accepted our position
… we talked about the media type issue
… ora made good arguments which convinced them
… It is small amount of text that will have to go into Concepts
ktk: only in Concepts?
AndyS: yes, better to put it in one place and then the other docs can refer to it
ktk: Doe JSON say anything about bad/wrong JSON?
AndyS: It's stronger in JSON because, there, you need to have the whole doc before you can start processing.
… whereas RDF formats can be processed in a streaming manner
pchampin: +1 to AndyS
… But the Turtle spec says that ??? is not specified
… My take is that an error must be signaled (how is up to the implementers)
<j22> json => A conforming processor of JSON texts should not accept any inputs that are not conforming JSON texts. A
<j22> conforming processor may impose semantic restrictions that limit the set of conforming JSON texts that it will
<j22> process.
pchampin: and give some leeway on how many triples should be used when an error is discovered
… It would be a shame to prevent one of the behaviors to be implemented
ktk: right! Example is the Web Data Commons dataset, which is huge and there are errors in these files
j22: There is a difference between conforming and the implementation choice
… the spec shouldn't forbid either way
AndyS: similar!
… The specs shouldn't say anything explicitly about what to do when going into recovery
Does anyone know any recovering parsers?
pchampin: I have some plans for NTriples and NQuads.
<niklasl> +1 to the non-conforming remarks; recovery/error-correction is too non-deterministic to encourage, IHMO.
AndyS: These are easier.
<william-vw> Recovering parsers are very common for HTML ; if RDF is presenting itself as a Web standard, perhaps they should also be at least allowed
pchampin: We should indeed not spec what recovery means, but leave this as a choice for implementers
AndyS: Ora did mention that issue in the TAG meeting
<pchampin> hence the importance of *signaling* the error :)
AndyS: it is not about individual triples but also about cases with multiple triples about a person.
j22: The Oracle parser and ??? was of a recovering parser.
<TallTed> a/and ??? was/and Virtuoso was/
j22: for instance broken literals that contain a snippet of Turtle inside
<niklasl> w3c/
<gb> Issue 189 Consolidate advice about versions of RDF syntax and HTTP access (by niklasl) [needs discussion] [ms:CR]
niklasl: I wrote a tracking issue for the details about how to explain this.
… I think we are in agreement that this should go into Concepts.
ktk: Was Sarven in the call?
pchampin: yes.
Review of open PRs, available at 4
ktk: Any PRs to merge?
… There are some new ones.
AndyS: ktk, what about Turtle 116 ?
ktk: can be merged
<ktk> w3c/
<gb> Pull Request 18 what properties can or should link to triple terms? (by rdfguy)
ktk: Are we waiting for something on this PR?
TallTed: I have a bunch of change requests in that PR, for Ora to take care of
<ktk> w3c/
<gb> Pull Request 21 Include common files by reference (by niklasl)
ktk: This one ready to merge?
niklasl: yes, I will merge it
<ktk> w3c/
<gb> Pull Request 36 update spec/common with the latest version (by pchampin)
niklasl: That one should be closed
pchampin: yes
… will do
<ktk> w3c/
<gb> Pull Request 66 Declare XSD 1.1 facets as rdf:Property and annotate them (by domel) [ms:future-work]
ktk: Did we have an agreement on this one?
Dominik_T: can be closed because there was no consensus on it
<niklasl> w3c/
<gb> Pull Request 135 Add content negotiation subsection (by niklasl)
pchampin: I can update the dashboard to not show PRs or issues tagged as future work
niklasl: This one can be closed as well, or revised completely to reference Concepts.
<Dominik_T> +1 for close w3c/
<gb> Issue 189 Consolidate advice about versions of RDF syntax and HTTP access (by niklasl) [needs discussion] [ms:CR]
Identifying issues to solve before CR 5
ktk: What do we need to finish the editor's notes?
pchampin: They are included by reference
ktk: Which is maintained where?
pchampin: in rdf-commons
ktk: Who will update this?
pchampin: I will make a PR in rdf-commons
ktk: and please reference the PR in this issue; then, we can close the issue
<ktk> w3c/
<gb> Issue 86 Evolving 1.2 triple term features : rdf:parseType, rdf:annotation (by afs) [ms:CR]
ktk: should this remain open?
AndyS: It tries to pull everything into one place
… There have been concerns that this affects RDF/XML 1.1 data.
ktk: What about the CR-related tracker issues?
AndyS: There is a suggested change.
… It does require a WG vote.
<ktk> w3c/
<AndyS> w3c/
AndyS: I will do something that is more focused.
<ktk> https://
niklasl: That's the one from today that I mentioned earlier.
… AndyS said hat we should discuss this
… May be at the next meeting.
AndyS: That would be a separate topic.
… related to the TAG response
Any Other Business (AOB), time permitting
ktk: In two weeks is KG Conf.
… Ora and I will be there (doing an RDF 1.2 presentation)
… I propose to cancel the meeting in that week,
<niklasl> +1 for PR chat
AndyS: If we have some PRs floating around, we can have a chat to advance on these.
… We can decide closer to the time whether we will use the time.
<TallTed> minimally programmed working session works for me. some minutes/notes might be useful.
pchampin: I will not be able to join next week.
… In two weeks, I can chair if needed.
<niklasl> speced/
niklasl: PR fixing dark mode in Respec merged
ktk: amazing :-)
niklasl: No need anymore to tinker with that for our specs specifically.
AndyS: Will that affect specs in other groups?
niklasl: yes
… You need to refresh you browser cache.