RDF-star WG biweekly focused meeting

Update about WG vote about triple terms in the subject position

ora: I wrote a summary of the vote
… and I got some more comments
… I need to take some time to analyse these comments
… this will be done before next meeting

james: if I am the target of the comments I am available for discussion

ora: I may need to contact you for some clarification

ora: AndyS, you sent a mail to the list commenting on RDF semantics
… do you have something to add to the agenda

enrico: regarding RDF semantics being ready for review
… we closed most of the PRs
… PR 91 is waiting for approval
… issue 49 needs decision
… I added another issue on interpoletion lemma
… we need to check if it still holds with the new semantics

ora: is it related to issue 76?

enrico: no, this is closed

enrico: the interpoletion lemma is important for SPARQL so we need to prove it

ktk: do we need to vote about this or do we start reviews when the PR is closed?

ora: no need for a vote

pchampin: publishing with echidna does not work anymore because the charter finished in February
… the new charter in place will make all work again

<pchampin> https://w3c.github.io/rdf-semantics/spec/

pchampin: but we still have the Editor's drafts
… we can use them if needed for our internal reviews

enrico: should my name be added to RDF 1.2 Semantics as an editor?

<pfps> add Enrico!

ora: absolutely yes

<pchampin> +1

map the annotation syntax to rdfs:states 1

ora: Thomas (who raised the issue) is not here today

gkellogg: the WG approved the syntax but we have not discussed Thomas' concerns and there has been evolution of the syntax in the meantime

TallTed: we shoud discuss this with Thomas before taking a decision

james: Thomas sent a message saying that because he is not present, he would not be able to argue on this issue

ora: we'll postpone the discussion

the change to replace "must" with "should" for ill-typed term values should be reverted pending further discussion 2

<pfps> From Thomas: t is unfortunate that i can't attend a meeting that has 3 issues that i raised on the agenda, so let me at least provide some comments.

<pfps> w.r.t. agenda items 2 and 4 i still think they'd both be valuable additions to RDF 1.2, but i don't see enough support for them right now and therefore am fine with moving them to the "maintenance" phase if no one else takes them up right now.

james: this issue is from me
… this change was made to the document without making enough discussion

<pchampin> Thomas wrote "w.r.t. agenda items 2 and 4 i still think they'd both be valuable additions to RDF 1.2, but i don't see enough support for them right now and therefore am fine with moving them to the "maintenance" phase if no one else takes them up right now" in https://lists.w3.org/Archives/Public/public-rdf-star-wg/2025Mar/0014.html

james: I consider it introduces a deficiency in the spec
… the argument from pfps is that a graph with ill-typed literal does not mean anything and therefore must be rejected, which I disagree with
… the argument that it is complicated to do is not receivable because I did it and I know it is not complicated to do

<Zakim> pfps, you wanted to disagree with the characterization of my stance

james: we need to know what the group would prefer to do

pfps: my argument was different
… I think it should be permissible for implementations to dismiss triples that have ill-typed literals
… it also permits interesting optimisations

TallTed: I feel strongly that the "MUST" is important

ora: also, implementations don't always follow the "MUST"s even when they are explicit

TallTed: I think it's not right to claim conformance and ignoring the MUST

james: there may be situation where we do something not in according with the standard, but this must be justified, while not having to change the standard

<TallTed> +1 departing from the spec *with documentation* (or better, with a switch) is far more acceptable

AndyS: it's unrealistic to enforce that claiming conformance requires proving *every* MUST is respected
… obligation to implement all MUST to claim conformance is too high a price

james: there are cases where there isn't conformance because there is a bug (unwanted), and other times, we do not conform for a reason we can argue for

gkellogg: it is so hard to get every MUST right
… "claiming conformance" is a broad phrase

gtw: if you decide that in your case you have reason not to implement, then there should be a "SHOULD"

TallTed: it is generally accepted that implementation can break a MUST if there is a recorded note that explain what and why breaks
… but being allowed to chose what to implement or not in the spec is a problem
… the MUST for interop, the SHOULD is for mostly interop

james: saying "I find it to hard to do" is not sufficient
… unless it is truly extremely hard to do

ktk: RDF is decades old and we know that this MUST is not as widely implemented as some may think
… it's clearly a SHOULD from existing practices

james: from pchampin's experiment, it was not conclusive whether implementations widely respect the MUST or not

<pfps> civility would be useful just now

TallTed: I am on james' side

<ora> STRAWPOLL: w3c/rdf-concepts#147 do you support "MUST" (as opposed to "SHOULD")?

<gb> Issue 147 the change to replace "must" with "should" for ill-typed term values should be reverted pending further discussion (by lisp) [needs discussion] [spec:substantive]

<AZ> +1 for MUST

<ktk> -1

<Tpt> -1 for SHOULD

<ora> -1

<pchampin> -1

<Souri> -1

<gtw> -1

<james> +1 for must

<pfps> -1

<doerthe> 0

<gkellogg> -1

<enrico> -1

<TallTed> +1 MUST

<niklasl> -1

<AndyS> 0 - don't care - Jena accepts ill-typed literals

<Dominik_T> -1

<olaf> -1

<eBremer> -1

niklasl: suppose there is an implementation that recognises xsd:boolean and nothing else
… what's the practical bad consequences if it supports or not the MUST?

ora: another way to put is "if we put SHOULD, do we achieve better interoperability overall, given that some implem don't conform at the moment"

gkellogg: it is odd to use MUST when ill-type depends on datatype support, which is optional

<niklasl> +1 to gkellogg

TallTed: the part with MUST extends the case when you do not recognise datatypes to the case when you recognise some of them
… if you put the wrong datatype on a string you should still be able to construct a graph

james: ill-formed terms are not different from normal terms when you don't recognise datatypes
… every documents should pass through every implementation in the same way

pchampin: ill-formed litteral in a datatype I don't support is very different from well-formed litteral when I support the datatype
… james, you keep objecting to the same argument ("difficult to implement") but never respond to the other arguments that have been raised ("reality of implementations", "potential for optimization")

james: a term that has an unknown datatype is not more or less problematic than a term with a known datatype

ora: can we get a consensus on this?

<TallTed> w3c/rdf-concepts#60

<gb> CLOSED Issue 60 Drop the requirement to support ill-typed literals with recognized datatype IRIs (by wouterbeek) [spec:enhancement]

ora: we can formally vote on this next time

TallTed: I will not formally object on this though

<ora> PROPOSAL: Adopt "SHOULD" for w3c/rdf-concepts#147

<gb> Issue 147 the change to replace "must" with "should" for ill-typed term values should be reverted pending further discussion (by lisp) [needs discussion] [spec:substantive]

<ktk> +1

james: I will not formally object either

<ora> +1

<Souri> +1

<Tpt> +1

<gtw> +1

<gkellogg> +1

<doerthe> +1

<eBremer> +1

<james> -1

<enrico> +1

<Dominik_T> +1

<olaf> +1

<TallTed> -0.7

<pfps> +1

<AZ> -0.86

<niklasl> +0.9

<james> -.99

<pchampin> +1

<AndyS> +0.5

RESOLUTION: : Adopt "SHOULD" for w3c/rdf-concepts#147

<gb> Issue 147 the change to replace "must" with "should" for ill-typed term values should be reverted pending further discussion (by lisp) [needs discussion] [spec:substantive]

TallTed: "-1" would mean that one is likely to formally object