Meeting minutes
Drop the requirement to support ill-typed literals with recognized datatype IRIs 1
pfps: The proposal is in the mailing list and in the issue.
<ktk> w3c/
AndyS: According to the minutes, the semantics TF wants to have a vote on an issue; correct?
<ktk> enrico: do you hear us? that question was for you
AndyS: on the updated baseline.
enrico: Yes.
<enrico> https://
ktk: We can add it to the agenda (after the first one)?
pchampin: Yes.
ktk: Back to ill-typed literal proposal.
pfps: The intent is important: to allow implementations to drop ill-typed values for recognized datatypes (with a MAY). These do not have any meaning.
AndyS: It was unclear what the text for accept or drop was. Do I read them in and then drop triples?
… If ill-typed values would be problematic for the set of implementations that recognize them.
james: We recognize them. It has been eminently useful to accept ill-typed literals to allow users to see that and correct them. Otherwise we would lose that. We think it is a bad idea to allow to drop them.
<Zakim> pfps, you wanted to ask for use cases involving ill-typed literals
james: They should be accepted into the graphs. They do not have to be considered for entailment regimes.
pfps: I'd like to see a use case for that.
james: As described. Users, for reasons we cannot explain, have datasets with invalid terms in them. The only way to process that was to indicate that to them and allow them to work in that. In the graph, using SPARQL.
Souri: Our experience is that users would like this to be pointed out as soon as possible.
… These are not designed; users need to know that early, and not put them in the graph; not to be changed after that.
… So a MUST on that would be problematic for us.
pchampin: The proposed change does not prevent implementations to accept them and inform users in such ways as james describe.
<Zakim> pchampin, you wanted to note that the proposed change does not prevent James' use-case to be supported
<Zakim> AndyS, you wanted to ask about recognized != D-entailment.
pchampin: So the use case does not seem to be a strong argument against allowing others to drop them (and handle that differently, before adding them to the graph).
AndyS: This does not go into details about full value processing. It is not, in the text, coupled with full(???) entailment.
james: ???
thomas: If we drop this requirement, we weaken our requirement for interoperability.
… in the implementation side it is not really an issue to have this as a must
… When integration and exchange of data is so important for RDF
ktk: I think one of the motivations is that there are a bunch of stores that drop ill-typed recognized literals. That's a reality.
<pchampin> +1 to ktk, there *are* currently implementations not following that MUST
james: What are the politics of non-conformance, then?
… Once we've done the D-entailment, we no longer do the comparison the same.
… Having a base standard that sets the standard, and not loosen it for others who do not comply.
gtw: This feels like preferential treatment of our spec above other specs. Such as the XSD spec. Why should we have normative text that says that users should ignore normative text in the XSD spec.
<pfps> It is strange, but that is the RDF way.
james: One could say that you MUST perform the test and you MUST reject them. But to open it up (???)
gtw: The SPARQL basis is a minimum base. Lot's of systems have support for other datatypes that are not normative in the spec. This would not impact those.
Souri: If someone says that the lexical value conforms to the spec for XSD integer, I would expect that they want that conformed to.
<james> w+
Souri: RDF's flexibility already provides users other means for that flexibility. Why should we in RDF allow specified XSD values that are not allowed by the XSD spec?
james: Your argument is that it should be changed to a reject.
<gtw> Current proposal would support both james' and Souri's approaches, yes?
james: The current proposal is to change from must accept to SHOULD accept. I get your argument that it should be changed to MUST reject?
Souri: That's what we do. We report it but do not store it
james: I would be more likely to concur with that. Because it's clear.
Souri: I'm OK with SHOULD (then I must not accept), but reject would be even better.
pchampin: That would be a breaking change (changing must allow to must reject).
… Not all implementations are SPARQL implementations, and not all recognize these.
… We have much more low-level and simpler implementations. That reflects the reality.
… The standard should reflect the reality, even if it is more complex.
AndyS: SPARQL isn't particularly relevant. It defines how to handle this independently without talking about recognized datatypes. It explains in expression evaluation what should happen for these datatypes.
… Those choices are independent from the choices here.
ktk: I propose we continue this discussion after more concrete proposals with different options.
Discussion & vote on the updated baseline
<pfps> A pointer to the document would be useful
<pchampin> https://
enrico: We had a final discussion. This alternative would work better than the voted one. The current baseline requires a strong notion of well-formedness. And allows only one reification predicate (rdf:reifies).
… There was discussion of alternative predicates. The strong well-formedness is a syntactic check. This alternative proposal says write whatever you want, the these predicates become instances of the ReificationProperty type.
… In this proposal there is more freedom, the impact is in the metamodel of your graph, as a "hint" of what you're really doing.
… The reason for the current baseline is that it disallows bad practices with meaningless results.
<william_vw> enrico was there an agreement on the name "ReificationProperty" (or is that still up for discussion)?
enrico: With this alternative baseline, that is allowed, e.g. john :believes TRIPLETERM, but it would define : believes to be a ReificationProperty.
william_vw: Is the name ReificationProperty agreed upon?
… Is that also what we're voting on?
enrico: I believe there is no commitment on the naming yet. We may even move away from "reification".
ktk: So the proposal is to replace the current baseline with this?
enrico: Yes
pchampin: For clarity, could we have two pointers confirmed, to current and alternative?
<enrico> Current voted baseline: https://
<enrico> Vote to replace the current voted baseline with the following: https://
<AndyS> current = previously voted on. 2024.07.18
<pchampin> new baseline: https://
This should be the voted current: https://
<pchampin> current baseline: https://
gkellogg: Both versions of the baseline include triple terms in the subject position. That should be extracted and considered separately.
… We have determined that one of the barriers of the subject position is RDF/XML (not necessarily JSON-LD)
<pchampin> I would consider that the "triple term as subject" is still negotiable. For me the essence of the new baseline is in the semantics.
AndyS: We discussed this too a bit. What is defined for the semantics, for the data model, and for concrete syntaxes. The semantics can be based on symmetric RDF.
<pchampin> +1 AndyS
AndyS: My personal preference is for the symmetric form for the semantics. That is not support for having it in the data model.
gtw: I am not sure why we should be voting on syntactic details here, but rather on semantics only.
<Zakim> gtw, you wanted to ask about the inclusion of Turtle syntax details in document being voted on
<thomas> Enrico in his latest mail to the mailinglist (https://
<thomas> * a decision whether triple terms MUST or SHOULD appear only in object position — currently the RDF Concepts document says “MUST";
<thomas> * a decision on the shortcut syntax for “reification” triples in Turtle." I understand that as: we vote on the semantics, but not subject position and syntactic sugar. To me that also includes other syntactic questions
gkellogg: No problem with the semantics allowing it. So symmetric RDF can be the basis for semantics.
pchampin: For me, we are voting on a direction which we think that the editors of the semantics should work with.
… The goal is to agree on a general direction, and the details should be based on a PR, not a wiki page.
<thomas> +1 to pchampin
enrico: The turtle syntax is there for people looking at it to understand quickly. I will comment it out for what we are voting on. The baseline is for the semantics document. We of course needs syntax to refer to that. At least some BNF.
… I believe there should be even for the semantics.
<AndyS> Call the Turtle syntax section as "non-normative" / example / Illustrative
<niklasl> +1 for AndyS
ktk: Yes, we can keep it in as non-normative.
gkellogg: When we need to write down things abstractly, there is a conflation problem. We might use an S-expression form.
<pchampin> Enrico, in RDF 1.1, the abstract syntax is what serves as BNF to define the semantics
<ktk> PROPOSAL: Replace the "current" baseline for semantics by the "alternative baseline" proposal.
<ktk> current = previously voted on 2024.07.18. Snapshot:
<ktk> "alternative baseline" proposal, which would replace the "current"
<pchampin> +1
<pfps> +1
<ktk> +1
<thomas> +1
<enrico> +1
<eBremer> +1
<william_vw> +1
<doerthe> +1
<olaf> +1
<gkellogg> +1
<fsasaki> +0
<AndyS> +1
<TallTed> +1
<gtw> +1
<niklasl> +1
<james> +0
RESOLUTION: Replace the current baseline for semantics by the alternative baseline proposal
<Souri> 0
<TallTed> best to include the timestamped oro hashed URIs in the RESOLUTION
pchampin: I will edit that into the resolution.