Meeting minutes
Quoted triples not mentioned in primer 1
ora: niklasl, you're editing the primer. what to do about this?
niklasl: I added this because there was an issue asking for what I am addressing with the linked PR.
<niklasl> w3c/
<gb> Pull Request 16 Add introduction of triple terms and accompanying Turtle examples (by niklasl) [needs discussion]
niklasl: we've had a discussion already. It's coming together.
gkellogg: is quoted triples not an archaic term? that's from the CG.
niklasl: yes. the title should be rephrased.
pchampin: I'm happy to edit the issue.
niklasl: I commented last week.
… I piggy-backed on this issue. Don't think the PR was possible to add. It's label needs discussion.
… content-wise, I dont' know if we want to debate something here.
pchampin: I haven't looked at latest changes yet.
niklasl: the trick is to keep it small enough. Important thing first. More editorial things...
… perhaps I should have done editorial errata first.
ora: how does the terminology change?
niklasl: quoted triples went away.
… they've been called "triple terms" (the syntactic structure).
ora: not only do we make these chnages, but should we inform the person who raised this?
… there may be a lot of these that external people raise. if we reply to each separately... that may be a lot of work.
gkellogg: I don't know if it's the same process to follow as a NOTE.
ora: then I think it's sufficient that when we close this, the person who opened it can, if interested, go see what's going on.
niklasl: there might be another issue which isn't raised on the primer.
… which William asked about. It would be useful if we were able to say something friendly about how to decide when reading the primer.
… reifiers vs. named graphs and how they relate.
ora: going to be an important piece to put in there.
… that can be a source of confusion for a lot of people.
niklasl: there's some discussion regarding the choice of examples.
… I would love for that to be a separate issue.
… if the wording is acceptable, then we could merge this to have something added, subsequently discuss the examples.
… I don't think it needs [this], would prefer not to. The primer has been used for many years, and haven't heard anyone raising issues regarding it.
… hard to determine what the most common thing will be here.
ora: based on how this group was started, may turn out to be an interest for people.
… my suggestion would be not to raise an issue at this point.
… I think the changes you've made here... can we just merge these now?
… anybody want to review this?
niklasl: I suspect not everyone has had the time. We could ask at the semantics meeting tomorrow.
ora: do that. if there's nothing, then just go for it.
niklasl: I'd love for pchampin to approve it, since you've requested changes.
pchampin: browsing quickly now.
niklasl: took most of what you suggested as-is.
… tried not to subconciously change wording according to my opinions.
ora: we need something for the minutes to reflect our course of action.
<ora> PROPOSAL: Niklas to check with William and merge afterwards
<ora> +1
<niklasl> +1
<AndyS> +1
<pchampin> +1
<gtw> +0 # not feeling totally up to date, but happy to go along with this
<ktk> +1
<AZ> +1
<gkellogg> +1
<james> +1
<TallTed> +1
pchampin: I suggest when you write resolution, you add reference to what needs to be merged.
… make text of resolution self-contained.
RESOLUTION: Niklas to check with William and merge afterwards w3c/
<gb> Pull Request 16 Add introduction of triple terms and accompanying Turtle examples (by niklasl) [needs discussion]
semantic conditions for ground graphs damaged 2
<james> was there not a recent discussion from the semantics group the a term should be permitted in the subject position?
gkellogg: did we discuss this last week?
… pchampin was to re-apply changes.
pchampin: yes.
ora: if pchampin hasn't done this yet, maybe this should be deferred.
pfps: sorry. audio issues.
… yes, this was discussed last week.
… maybe the thing to do is to undo the PR for now, and pchampin can put in a new PR later.
… I don't know how to undo a PR.
… (that's been merged)
gkellogg: can reset the HEAD rather than a commit that undoes it.
AndyS: git revert. will still be in the log.
pfps: somebody who understands that better than I should do it.
pchampin: can git-revert do multiple commits at the same time?
AndyS: one at a time. only talking about HEAD of main, though.
… can re-organize locally and repush. will have to take branch protection off.
pchampin: I will figure it out. Unless somebody objects to a force-push...
… any solution is OK unless somebody objects.
ora: undo/revert. then re-apply the editorial?
pchampin: then a new PR with as well-documented as I can editorial changes.
AndyS: I was wrong. It's only the merge request that's the HEAD. there are a lot of commits.
… I thought they had been squashed, but they haven't.
… back to May 2nd.
<ora> PROPOSAL: pchampin to revert/undo the merge, then create new PR with select editorial changes
<pfps> +1
<ora> +1
<gkellogg> +1
<TallTed> +1
<gtw> +1
<niklasl> +1
<ktk> +1
<james> +1
<pchampin> +1
<AZ> +1
gkellogg: if each of multiple selections is committed individually, creates a big history. instead, use batch mechanism from file view to reduce number of commits.
… alternatively, when merging, do a squash commit to leave a clean trail.
RESOLUTION: pchampin to revert/undo the merge, then create new PR with select editorial changes w3c/
<gb> MERGED Pull Request 52 Better HTML (by domel) [spec:editorial]
AndyS: or squash locally, force-push to the branch.
pchampin: I can do the substitute.
<AndyS> +1 and thanks to Dominik for the work he's done.
ktk: who will do the new PR?
pchampin: I will.
Drop the requirement to support ill-typed literals with recognized datatype IRIs 3
ktk: what is the conclusion on this one?
AndyS: I dug around in the history a bit. Found that rdf 1.1 mentions this.
… mention in concepts was new in 1.1. Datatypes map from 1.0 that was in the model theory.
… can find no other use of requried datatypes other than in semantics.
… semantics needs it to give us a base for building extensions on top of.
… can find no system with documentation with "supported datatypes".
… my proposal is to put it back into 1.1 semantics.
… certain datatypes required, not mentioned in concepts.
gkellogg: we're not modifying 1.1 semantics.
AndyS: we're keeping it in 1.2 semantics, but not having it in 1.2 concepts.
<Zakim> pfps, you wanted to ask whether we are talking about required or recognized data types
pfps: I'm confused. Are we talking about recognized or required datatypes.
AndyS: phrase is "required"
pfps: items have "recognized".
… item we are on is "Drop the requirement to support ill-typed literals with recognized datatype IRIs", not "required datatypes".
AndyS: should have said "recognized". semantics does put requirements on the "recognized" set.
pfps: not sure why that is relevant.
AndyS: I am suggesting taking it out of concepts. Seems to have no purpose except to support extensions.
pfps: why is that relevant to discussion of "recognized" datatypes?
pchampin: the normative statement we are discussing is from rdf concepts.
… what AndyS is suggesting is that we remove that statement as well as all other metnions of "recognized datatypes" because they don't have interest in rdf concepts.
… would solve issue and make specs more consistent.
ora: the only required datatypes are string and something else...?
AndyS: in rdf semantics, string and langString. I presume we would add langString as well.
… in rdf 1.0, it's not described like that, but also rdf:XML which was mandated.
… that's now a datatype like any other.
gkellogg: as well as rdf:HTML
AndyS: and a few others. those were never required.
james: I'm trying to understand the consequence of removing the requirement for recognized datatypes.
… would that mean that treatment of datatypes of terms where the syntax does not match that specified for the datatype, that treatment becomes undefined?
AndyS: no, because in RDF concepts, we only have datatype terms. we don't have any meaning to the datatypes.
… it's just a lexical form and a datatype.
… if you're not matching the datatype, whether you understand it or not, it's outside of rdf concepts.
… base to build simple semantics. from there, other entailments defined in 1.2 document...
gkellogg: I think it comes down to XML scheme built-in datatypes are recommended but not required in concepts.
… has the notion of value space as well as lexical space.
… concern is about xsd types that are malformed.
… given that they are recommended in concepts, implementations do not need to recognize these datatypes but we don't say what the behavior should be if they are recognized.
… especially regarding ill-typed.
AndyS: xsd datatypes are really there for different purpose.
… e.g. if we're going to have numbers/dates/etc., let's use that instead of a new way to do that.
pchampin: looking at rdf 1.1 semantics, I seem to remember there was something that gave some implementation leeway when the graph is unsatisfiable.
… if I'm right, then this would contradict the statement we're talking about in concepts.
… an ill-typed literal would make the graph unsatisfiable.
… that's why I like the proposal to defer this to semantics. the reason to not support ill-formed recognized datatypes is since the graph is inconsistent, the impl may not want to bother with dealing with that and just throw an error.
<niklasl> "If the literal is ill-typed then the L2V(I(aaa)) mapping has no value, and so the literal cannot denote anything. In this case, any triple containing the literal must be false. Thus, any triple, and hence any graph, containing an ill-typed literal will be D-unsatisfiable, i.e. false in every D-interpretation." from
<niklasl> https://
pchampin: I think that makes sense. Somehow permited by rdf semantics at this point, so why should it be forbidden by concepts.
pfps: in rdf 1.1 semantics, there was a change.
… in 1.0 ill-typed literals did not make the graph inconsistent.
… in 1.1, they do.
pchampin: maybe this statement in concepts in related to that in 1.0.
ora: this makes me think since this is hard for us, we should somehow spell out exactly what it is that we are hoping/expecting implementations to do.
AndyS: my hope is it makes no difference.
… the set of recognized datatypes really has to be something implementations declare.
… as far as i can see, nobody is doing that.
… not the case of syntactic conformance to the datatype.
… in XSD, the numbers have value constraints as well as lexical constraints.
ora: how are implementations supposed to declare this?
AndyS: we don't have mechanisms to do that.
ora: only remotely remeniscent mechanism is SPARQL implementations disclosing entailment regimes.
AndyS: most in SPARQL happens because you perform arithmatic on datatypes. rules from F&O applies even when you're in simple entailment.
… that's why it's difficult to probe what SPARQL systems do.
ora: let's for a moment ignore that we don't have such a mechanism. pretend there is one. we should have a clear recipe for implementations as to how they should behave.
… or not behave.
AndyS: at the moment, says "MUST accept ill-defined literals".
<AZ> Re. what pchampin said: In RDF 1.1 Semantics, Section 7.2 says "RDF processors MAY treat an unsatisfiable graph as signaling an error condition, but this is not required."
<pchampin> https://
pchampin: I found what I had remembered. section 7.2.
… rdf 1.1 concepts and semantics are inconsistent with each other.
… "you MUST support" vs. "you MAY signal an error"
ora: that and the fact that ill-formed literals lead to unsatisfiable graph.
pchampin: yes. since rdf 1.1.
… RDF processors may signal an error.
james: MAY do that if they're doing D-entailment is what you read.
pchampin: only makes sense with D-entailment.
james: not required anywhere that they do D-entailment.
… different for SPARQL processors vs. RDF stores.
pchampin: I agree. The phrasing refers to "recognized types", which I think is only defined with respect to D-entailment.
ora: we would do a service to the community if we spelled this out for people.
AndyS: if we remove it, we're doing what everyone has been doing up to now.
ora: not only spell it out but define anomalous behavior.
AndyS: nowhere in the specs touches on this as a round-trip requirement.
… just "RDF processors" with undefined behavior.
… valuable for products to make product decisions about what is allowed.
james: the simplest simplistic formulation might be if you are doing D-entailment, you MUST reject. If not, you MUST accept.
… people might not conform for product reasons, but would improve expectations.
AZ: I think what RDF concepts and semantics say is not necessarily inconsistent.
… may be talking about different things.
<pchampin> james, I'm not sure I like "improving expectations" if we envision that tools won't meet these expectations
AZ: example of ontologies in OWL can be inconsistent. You can have tools that open inconsistent ontologies like Protoge.
… no problem. But when you try to do reasoning, then it brings an error.
… maybe what concepts is talking about is different than what semantics is talking about.
<pfps> I agree with Antoine, actually the reasoning might not even signal an "error" but just complain about inconsistency and proceed.
AZ: parser should handle any literal. but if you want to do some processes later on the data you parsed, maybe can raise an error. but that's at a different level.
… this is what should be specified more clearly.
ora: so a layered approach. parsing can turn into a graph, but can't do whatever reasoning you want. different things.
<pchampin> +1 AZ, the problem of this MUST is that it is not granular enough
ora: still, I think we need to be clear on this and spell it out.
AndyS: don't we have the structure for saying that? Isn't that simple entailment?
ora: if you don't do D-entailment, isn't that what we conluded a moment ago?
AndyS: everything must be build on simple entailment. that defines truth.
pchampin: I really like AZ's suggestion.
… talking about simple entailment is not the same thing.
… some components don't do entailment. parser is just here to transform a string into triples.
… like the idea that a parser should forward any triple it finds that is syntactically valid.
… but then the storage layer may reject based on some storage constraints.
… I don't like the MUST because it's not granular enough.
… if we talk about entailment, we are already pinning this to a specific kind of component.
… I don't think that's the right thing to do.
… I wouldn't like my turtle parser to choke on ill-formed literals. Happy for storage to not allow me to put them in.
niklasl: I agree with that from user perspective.
<james> pchampin: clarity as to which component supports what would reduce ambiguity.
niklasl: if I had system with entailment built in. If I know that my implementation has D-entailment.
<pchampin> and that's where "SHOULD support" would leave it to implementers discretion
niklasl: more problem having it keep around boolean values with invalid values. not the contract I expect it to fill.
ora: I will try to take a stab at writing this out in an understandable way.
AndyS: related thing is are we going to take it out of concepts? leave it just in semantics.
ora: I don't know how to answer that. Think we need a paragraph or two somewhere that spells it out.
<TallTed> I think moving it to semantics makes most sense
<TallTed> yes, spelled out better would also be good. :-) I'll try to help with text once it hits a PR.
<niklasl> +1