Meeting minutes
<pfps> I have to leave in about 70 minutes.
discuss the open issues and pull requests in RDF-semantics as suggested in this email by pfps.
<pfps> w3c/
<gb> Issue 130 vocabulary to refer to the individual nodes in a triple term (by rat10) [needs discussion]
<pfps> This could have impact on semantics if <<(:a :b :c)>> rdf:subject :a. is an axiomatic triple.
<niklasl> I think it was confused with w3c/
<gb> Issue 49 Define an interpretation of Triple Terms (by niklasl) [needs discussion]
<pfps> so that's a consensus that this issue, if ever addressed, cannot have any semantics impact
<niklasl> I agree
<enrico> I find hard to see that it shouldn't have semantics. So, it is just a usage pattern personal to tl
<pfps> w3c/
<gb> Issue 87 A formal background to unify triples and triple terms (by franconi) [spec:substantive]
<pfps> I think that this proposal has flaws and should not be added to Semantics at this late stage.
<niklasl> This is bring added to the spec via w3c/
<gb> Pull Request 91 A formal background to unify triples and triple terms (by franconi) [spec:substantive]
<pfps> if this is only adding new stuff that doesn't affect the real semantics then we can let it go for now
<niklasl> I am all for merging 91 (it is very useful to explain things).
<niklasl> It is the only way to explain what where doing...
<pfps> w3c/
<gb> Issue 114 Un-star operation to support RDF Dataset Canonicalization? (by niklasl) [needs discussion]
<pfps> I believe that this issue should not affect Semantics, either directly or indirectly through any changes that it would make in Concepts. The meeting could vote to make this a requirement of unstar.
<doerthe> but let's please fix the one comment I had for w3c/
<gb> CLOSED Issue 91 JSON values (by pfps) [propose closing]
<tl> +1 to pfps - define unstar as just a mechanical transformation with no effect on semantics
<AndyS> RDF Concepts section 8: "the output graph is not semantically equivalent to the input graph"
<pfps> Define an interpretation of Triple Terms #49 w3c/
<pfps> I believe that this issue is already handled by the semantics in Semantics. Changes are, of course, possible. The meeting could vote to close the issue based on this.
<gb> Issue 49 Define an interpretation of Triple Terms (by niklasl) [needs discussion]
<gb> CLOSED Action 49 put in the repo the "source of truth" for labels (on pchampin) due 13 Apr 2023
<pfps> OK, consensus is that anything done for this won't affect semantics
<pfps> what properties can or should link to triple terms? w3c/
<pfps> I believe that this issue has been resolved by the wording about rdf:reifies in Concepts and there are currently no implications on Semantics. The meeting could vote to recommend that the issue be closed based on this.
<gb> Issue 127 what properties can or should link to triple terms? (by afs) [needs discussion]
<pfps> as far as semantics is concerned the only effect on Semantics is that rdf:reifies has a built-in range?
<pfps> map the annotation syntax to rdfs:states w3c/
<pfps> This is an alternative way to do annotated triples. It's currently not in the documents.
<gb> Issue 128 map the annotation syntax to `rdfs:states` (by rat10) [needs discussion] [propose closing]
<pfps> consensus is that this won't be done
<pfps> the change to replace "must" with "should" for ill-typed term values should be reverted pending further discussion w3c/
<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]
<pfps> I believe that there are no effects to the semantics arising from this issue, as the RDF semantics is just about satisfaction and entailment and should not be concerned with other behaviour.
<pfps> consensus is that there will not be any semantics effects
<pfps> Explain how classic RDF reification relates to triple terms and rdf:reifies w3c/
<pfps> My view is that this is not something that should go in Semantics.
<gb> Issue 61 Explain how classic RDF reification relates to triple terms and rdf:reifies (by niklasl) [propose closing] [spec:editorial]
<pfps> consensus is to put this in Primer or elsewhere particularly with move of some other stuff
<pfps> consensus is that in any case there is not effect on the formal semantics
<pfps> completeness of entailment w3c/
<pfps> I created a PR (#101) that qualifies everything. I think we can merge the PR. Hopefully we can iron out enough of the above issues that at least the interpolation lemma can be proven.
<gb> Issue 76 completeness of entailment (by pfps) [needs discussion] [spec:substantive]
<gb> CLOSED Action 101 add the rdf-star-wg repo to the dashboard [1] (on pchampin) due 2023-12-21
<gb> Issue 152 Explain how classic RDF reification relates to triple terms and rdf:reifies (by niklasl) [propose closing]
<doerthe> maybe we could discuss it next week?
<pfps> PR #91 to be merged as it is approved and related to semantics
<gb> CLOSED Issue 91 JSON values (by pfps) [propose closing]
<pfps> identity and equality of datatype values w3c/
<pfps> I think the task force should state that it is important to make clear what RDF equality means between literal values, i.e., that the denotations of +0 and -0 in any RDF datatype that includes IEEE floating point are not equal as far as RDF is concerned even though they compare equal in IEEE floating point.
<gb> Issue 92 identity and equality of datatype values (by pfps) [spec:editorial]
<AndyS> https://
<AndyS> Equality is identity, except that 0 = −0 (although they are not identical) and NaN ≠ NaN (although NaN is of course identical to itself).
<doerthe> :)
<pfps> so it is the feeling that there should be no more changes to the formal semantics
<niklasl> https://
<gb> Pull Request 91 A formal background to unify triples and triple terms (by franconi) [spec:substantive]
<enrico> Once PR 91 and issues 98/85/76 are closed, the text of Semantics can be considered ready for review (note: these issues are only about remove text)
<TallTed> These minutes could be cleaned up a lot, best with access to the IRC log. Doing it through bot commands would be quite painful and time consuming. Maybe pchampin can do something when he returns.