Meeting minutes
<TallTed> draft minutes
<gb> Issue 114 Un-star operation to support RDF Dataset Canonicalization? (by niklasl) [needs discussion] [discuss-f2f]
<gb> Issue 26 shape languages and validation features (by phtyson) [discuss-f2f] [needs discussion]
<gb> Issue 127 Material about `rdf:ReificationProperty` (by afs) [needs discussion] [discuss-f2f]
<gb> Issue 156 Addressing SPARQL EXISTS errata (by afs) [discuss-f2f] [needs discussion]
<gb> Issue 49 Define an interpretation of Triple Terms (by niklasl) [discuss-f2f] [needs discussion]
[annoying construction noise]
<gb> Issue 127 Material about `rdf:ReificationProperty` (by afs) [needs discussion] [discuss-f2f]
<gb> Issue 26 shape languages and validation features (by phtyson) [discuss-f2f] [needs discussion]
<gb> Issue 114 Un-star operation to support RDF Dataset Canonicalization? (by niklasl) [needs discussion] [discuss-f2f]
<gb> Issue 156 Addressing SPARQL EXISTS errata (by afs) [discuss-f2f] [needs discussion]
<gb> Issue 49 Define an interpretation of Triple Terms (by niklasl) [discuss-f2f] [needs discussion]
Un-star operation to support RDF Dataset Canonicalization? 1
niklasl: I tried to summarize the two options on the table: unstar based on named graphs, or base on classical reification
<william_vw> present_
niklasl: also the question whether it is targetting canonicalization alone, or more general
… if c14n was defined on RDF 1.2 with triple terms, unstar would not be necessary.
pfps: as far as I'm concerned, this group does not need to do anything about c14n.
… We could be nice, but not spend to much effort about this.
… We could say "RDF-CANON should be extended to RDF 1.2. In the mean time, use an unstar mapping that essentially uses reification."
<pfps> This should be specified a bit more precisely.
tl: I agree that we should provide a reification-based unstar mapping, that does not require named graphs.
… Several variants are described in the github issue, I think the reification-based is the less controversial.
niklasl: we need to know what the type of triple terms is.
gkellogg_: although the unstar is necessary for c14n, there are probably other cases that require it.
… I think round-tripping is important.
… We must consider SPARQL as well, being able to run it on an RDF 1.1 database.
<niklasl> +1 to "unstar a query" too (to put annotation in existing graph stores and use it in production)
gkellogg_: It would also be interesting to be able to turn standard reification into triple terms.
<niklasl> (noting that I have no problem "unstarring queries" manually)
ora: could be an issue if there is a mix of old-style and new-style.
gkellogg_; we need to decide if that's a problem.
<niklasl> +1 to that to (is the target 1.2 basic or 1.1)
<pfps> In my opinion an unstar mapping is only to be used as an interim solution. It does not have to support round-tripping. It does not need to preserve non-isomorphism for RDF graphs that are not "good" RDF 1.2 graphs (misusing rdf:reifies, misusing triple terms, not well-formed if we still have this).
AndyS: we need to decide if we are turning RDF 1.2 Full into RDF 1.2 Classic or into RDF 1.1. RDF 1.2 has text direction, RDF 1.1 does not. The algorithm would not be the same.
gkellogg_: I claim that base direction would not impact c14n.
… In the sense that it can easily be integrated in the existing algorithm.
pfps: given that there is more than c14n does not handle, I say we don't do anything.
ora: who's gonna get hurt if we don't do anything?
gkellogg_: the c14n algorithm is not so complicated, but the proof that it's correct are.
… It is not likely that a new group is going to be chartered to do a new algorithm.
… If we don't provide an unstar mapping, the RCH group would probably provide one.
… We do have the Full and Basic profiles.
pchampin: I simpathise with pfps position, but agree that if we don't do it someone else will.
… I believe there are other use cases for un-star.
… This provides a useful way to go between profiles.
<tl> I think we should do it (backwards compatibility, and illustrate the meaning of triple terms), and re @AndyS its target should be RDF 1.1
AndyS: I think we should do something, especially since the CG report already mentions an unstar mapping.
<niklasl> This issue has mutated a bit, and should perhaps be retitled again, to e.g. "Define an unstarred form into RDF 1.1(?)" (to cater for everything specified and/or deployed, including C14N and reasoners, that will not upgrade to RDF 1.2 overnight)?
AndyS: does not have to be a big thing, can be non-normative.
ora: if there are other use-cases for this than c14n, we run the risk that other people do it differently.
… We are in the best position to do it.
… What are our use-cases? Is it someone who wants to use RDF 1.2 with their RDF 1.1 implementation?
<Zakim> pfps, you wanted to point out that https://
ora: Other question is round-tripping.
pfps: the RDF-CANON has a big problem, it is unclear about what its input is.
… The input is an n-quads documents, but in other places it talks about the input dataset.
… I don't want us to get involved in this.
… It is not up to us to fix that problem.
gkellogg_: you seem to be asserting that it is a flawed recommendation.
<pfps> From RDF canonicalization "This document outlines an algorithm for generating a canonical serialization of an RDF dataset given an RDF dataset as input."
gkellogg_: It uses n-quads as an input to leverage the blank node labels.
<pfps> From the docuemnt "input dataset
<pfps> The abstract RDF dataset that is provided as input to the algorithm."
gkellogg_: It was reviewed and I think it is an adequate recommdnation.
<pchampin> s/recommndnation/recommendation
<pfps> The algorithm, however, starts with an N-quads document.
niklasl: I think the argument about migrating from RDF 1.1 is a good one.
<tl> +1 to niklasl
pchampin: I think we should use RDF 1.2 Classic as the baseline, not RDF 1.1.
niklasl: I sympathise with this position.
<william_vw> I assume RDF 1.2 classic means without triple terms?
niklasl: There are ways in JSON-LD 1.1 to encode base direction in RDF 1.1, but there are two options, none of them ideal.
ora: what would it require to deal with base direction in RDF 1.1?
<tl> @william_vw yes
<william_vw> @tl thanks
gkellogg_: we would probably go with one of the JSON-LD options, probably the i18n datatype.
<niklasl> I'd agree on i18n datatype version of lang-literals-with-dir.
ora: I don't like the idea to deem this somebody else's problem
… Depends how much work we want to put into it, pieces of solution already exist.
pchampin: I agree that we need to do something. But, let's be clear on what we're trying to solve.
… I'm worried about using RDF 1.1 as a baseline.
… It's also useful for the "inter-profile" operation.
… If we agree that this is the scope, I can take it into account in my PR.
ora: it would solve the c14n "for free". Ultimately RDF-CANON has to be adapted to RDF 1.2, but we know it may take time.
<ora> STRAWPOLL: Should we include an un-star algorithm in the 1.2 spec? (some questions remain...)
<pfps> -1
<niklasl> +1
<gkellogg_> +1
<tl> +1
<ora> +1
<william_vw> +1
<MacTed> +1
<olaf> +1
<pchampin> +1
<AndyS> +1
<Dominik_T> -0.5
gtw: what would normative mean? not all implementations need the unstar mapping?
pchampin: it needs to be normative if other specs want to normatively refer to it.
gkellogg_: implementations can be compliant without passing all the tests
<gtw> +1
gtw: the manifest vocabulary allows us to flag tests as requiring certain features
tl: it seems like a straightforward implementation, not putting unreasonable burden on implementations, so let's make it normative
<niklasl> I like this direction (not requiring 1.2 implementations to have an unstar operation plus adding a new set of tests for this feature (usable to opt-in for those who support it)).
ora: if we didn't make it normative, that would nudge the RCH group to do the work properly
AndyS: the more tests we put, the more work that is, and the less likely it is that implementations migrate
ora: I don't know the answer to this normative/non-normative thing. If we make a non-normative section, then people will hopefully not make their own.
… If some days the RCH group makes a 1.2, this is an interim solution.
pchampin: in the interest of time, I suggest we defer the nonrmative/non-normative question until we have a PR to discuss on
<gb> Issue 114 Un-star operation to support RDF Dataset Canonicalization? (by niklasl) [needs discussion] [discuss-f2f]
<gb> Issue 26 shape languages and validation features (by phtyson) [discuss-f2f] [needs discussion]
<gb> Issue 127 Material about `rdf:ReificationProperty` (by afs) [needs discussion] [discuss-f2f]
<gb> Issue 156 Addressing SPARQL EXISTS errata (by afs) [discuss-f2f] [needs discussion]
<niklasl> I see no big risk in just making it informative. (Famous last words; but... In practice, for "reasons", lots of implementations aren't 1:1 with what's normative.)
<gb> Issue 49 Define an interpretation of Triple Terms (by niklasl) [discuss-f2f] [needs discussion]
<niklasl> I see no *big* risk in just making it informative. (Famous last words; but... In practice, for "reasons", lots of implementations aren't 1:1 with what's normative.)
Material about rdf:ReificationProperty 3
AndyS: there is a not of the Semantics TF meeting, Friday 13 September.
… These are my notes for that, they are not formally agreed.
AndyS: I think the key point in there is that there are really only two options. Intermediate optiosn do not work out.
pfps: I believe this discussion should be deferred until we have several reifying properties.
<Zakim> gkellogg_, you wanted to point out that rdf:ReificationProperty is not a property, but a class. Perhaps there's a better name to use.
gkellogg_: noting that ReificationProperty is not a property but a class. Naming it that way can be confusing.
… Defining rdf:reifies without class defining its behaviours makes it a bit magical.
… Defining its behaviour in a class makes more sense to me.
<AndyS> +1 to renaming -- e.g. "rdf:ReificationPropertyClass"
tl: I'm promoting that other reification properties exists (e.g. rdfs:states), but I would also let anyone define their own reification properties.
<niklasl> The name does follow the naming pattern of rdf:Property, owl:ObjectProperty, owl:DatatypeProperty though?
<pfps> Oops, in trying to set up my headphone, I cut off all sound.
<pfps> I note that rdf:type is not a member of a class.
ora: about the name: yes it is a class, but we have other classes whose name ends with "Property" (rdf:Property, owl:TransitiveProperty)
… so this is not an issue.
<doerthe> I think pfps should go first
AndyS: I agree that there are others
<niklasl> rdf:type a rdf:Property # ?
pfps: I don't see why we need to do this. rdf:type is special, it does not belong to a class.
<doerthe> isn't rdf:type an rdf:Property?
<tl> @pfps the reason is that we want to somehow describe how to use triple terms
doerthe: isn't rdf:type an rdf:Property, not a specia one, but still a property.
<AndyS> rdf:ReificationProperty -- https://
doerthe: The goal of ReificationProperty was to help people find out that a property was used with a triple term as object. Not more, not less.
… I don't see why adding "Class" to the name of ReificationProperty.
… I agree that we should discuss whether we want other reifictaion properties.
<william_vw> thanks everyone - I need to leave to attend a school assembly here
pchampin: -1 to rename rdf:ReificationProperty to rdf:ReificationPropertyClass. Names matter.
… +1 to what doerthe said; the goal of the ReificationProperty class was to flag properties based on.
… I'm not a big fan of ReificationProperty either. But, I don't see there's any special behavior. It's just a flag.
… Another way to flag properties that are used with TripleTerms is to make them sub-properties of rdf:reifies, but that would cross over to RDFS.
… Instead of saying that any property of type ReificationProperty is has behavior, make them sub=properties of rdf:reifies.
<tl> +1 to that
ora: what is the hypothetical effect that this has on implementers?
… If we say that rdf:reifies is a special property without putting it in a specia class, does it give implementers more latitude?
… I don't have the answer but I think yes.
pchampin: In my opinion it doesn't give more or less latitude to implementors.
AndyS: IIRC ReificationProperty was introduced by Enrico to replace the well-formed-ness condition.
… Previous properties were "reserving" rdf:reifies to be used in precise contexts, which make it a very special property.
ora: if rdf:reifies is a special property, similar to rdf:type, do we have examples or subproperties of rdf:type?
gkellogg_: Schema.org defines a subclass of rdf:type.
<niklasl> Yes, schema:additionalType is explicitly defined as rdfs:subPropertyOf rdf:type
tl: I like the idea of using rdfs:subPropertyOf
… Also, I concur with AndyS about the origin of Reification Property.
niklasl: I am not sure what I think about the subProperty solution. I also concur with AndyS.
… These properties have a special range, I think this was Enrico's point.
doerthe: I don't have an opinion yet about the subProperty solution. I don't know what it would do.
… Do we want to have a range for rdf:reifies?
<AndyS> It's not range but RDF concepts (editors working draft) has https://
gkellogg_: I think we have discussed having a range for rdf:reifies of rdf:TripleTerm.
… This also came up in the discussion about unstar.
<doerthe> I am just afraid that we add a triple term class and make it the range or rdf:reifies
gkellogg_: the type rdf:TripleTerm is used to indicate that a blank node is representing a triple term.
niklasl: I agree. There was a discussion about naming it rdf:Triple vs. rdf:TripleTerm, but that's a separate discussion.
gtw: I mentioned SPIN before, where you don't necessarily want to set a range.
… We don't necessarily want to force a range on all reifying properties.
doerthe: the moment we set a range on rdf:reifies, I would disagree with the subProperty solution.
<MacTed> rangeIncludes ?
pchampin: I agree with doerthe and would vote against my own proposal if we have a range for rdf:reifies.
… I can see a range argument, and if we want it to be part of RDF Semantics, it's not good to mix. I see many drawbacks.
niklasl: we haven't talked about what Reification Property would mean.
… If it is just a marker, there is not much impact.
TallTed: it occurs to me that this may be a place where schema.org's rangeIncludes and domainIncludes can be useful.
<tl> I had that discussion with Greg Williams and though that when mixing ways to represent triple terms it's not surprising that issues occur. Apart from that, maybe I'm just ignorant so I would like to see examples from e.g. Dörthe
TallTed: These are not enforced schemata.
ora: I feel we should hear Enrico on this. Let's encourage him to read the minutes, and pick this up next Thursday.
pchampin: +1
<niklasl> +1
<tl> +1
<TallTed> we should perhaps close the items we've addressed (e.g., un-star)?
Shape languages and validation features 2
<ora> PROPOSAL: Mark as out-of-scope and close
<gkellogg_> +1
<pchampin> +1
<tl> +1
<ora> +1
<gtw> +1
<doerthe> +1
<niklasl> +1
<TallTed> +1
<eBremer> +1
<Dominik_T> +0.5
<AndyS> +1
RESOLUTION: Mark as out-of-scope and close
syntax for reifiers
<doerthe> I have to leave, sorry
ora: I think the main point of contention is whether this is prefix or postfix
gkellogg_: that, and tilda versus pipe or other characters.
ora: AndyS, you make a point about ease of parsing
AndyS: not just that. The pipe is already used in SPARQL, although there are ways around that.
… Enrico made the point that in N-Triples, the reifier comes first (in the subject position).
… I think that internal consistency in Turtle is more important.
tl: I made a few proposals, including the use of pipe everywhere, and replacing the curly brackets in the annotation syntax.
… I think we should have looked at the problem that way.
… I find Enrico's argument about the position in N-Triples irrelevant.
ora: you are saying this is a usability issue.
tl: yes, it is the interface, it is important to get this right.
niklasl: I agree, affordances are important, that's why the pipe is tricky because of its use in SPARQL.
pchampin: I agree that this is turnning into a broad discussion we can't do in a short amount of time.
… We can consider suffix vs. prefix and separately the tokens used.
niklasl: agreed, long prefix makes things hard to read
<ora> STRAWPOLL: Postfix?
<ora> +1
<gkellogg_> +1
<pchampin> +1
<tl> +1
<niklasl> +1
<pfps> 0
<Dominik_T> 0
<gtw> +1
<TallTed> +1
<AndyS> +1
<eBremer> +1
<ktk> +1
<ktk> Tpt: are you around?
<Tpt> I am back
Ora: there is still the question of which character we choose
ora: There are arguments against |
ora: There will re reifirers without annotations blocks and annotation blocks without reifiers
ora: if you see an annotation block after a reifier, it is related to this reifier so there is some memory needed
<tl> my 5cents on syntax: https://
AndyS: it's easier than doing RDF list
gtw: Have we a concised summary of the various syntaxes?
<AndyS> https://
<pchampin> << :s :p :o ~ :r >>.
<tl> Souri asked for that
<niklasl> I tried to have a bunch of variants appear "naturally" in https://
tl: I would like to point this syntax proposal but I thought we would do syntax later : https://
<pchampin> :s :p :o ~ :r1 ~ :r2 {| :a :b |}.
gkellogg: you can insert more than 1 annotation or refifier
<pchampin> :s :p :o ~ :r1 ~ :r2 {| :a :b |} ~ :r3.
gkellogg: in any order
pchampin: if there is no reifier before annotations, the reifier is a blank node
AndyS: what I find odd is that the annotation block have to have at least one predicate object inside
AndyS: it makes generating this kind of syntax from a program more complicated
<niklasl> That empty annotation blocks weren't allowed did trip me up in my introductory slide (8) for annotation sugar.
ora: Both Turtle and SPARQL use predicateObjectList+
<niklasl> So +1 from me for allowing it. Makes it easier to save hand-edited, unfinished turtle...
<tl> from my proposal: { :s1 :p :o . :s2 :p :o | :r1 } [| :a :b |] .
<AndyS> :s :p :o ~ :r1 ~ :r2 {| :a :b |} {| :c :d |}
<niklasl> <s> :p <o> ~ <r1> {| a :Named |} . <s> :p <o> ~ <r1> ~ {| a :NotNamed |} .
AndyS: Are you suggesting we have an empty annotation block to "cancel" the preceding reifier?
<niklasl> See above line. :)
gkellogg: you can do "~ {|" to get a blank node
<tl> from my proposal: <| :s :p :o | :r |> :a :b .
tl: We should keep {} for group of statements, not annotations
tl: If we change the abstract reified triple to <<| we use pipes everywhere
tl: That way the pipe would be everywhere we use RDF-*
gkellogg: I am afraid it collide with N3 where they use | for object paths
gkellogg: the triple object can be a path, and I believe it can include "|"
gkellogg: This would be against a bare pipe
<Dominik_T> gkellogg can you provide a link or an example where in N3 pipe can be used?
pchampin: I would like to come back to the previous topic, my personal opinion is that ~ without identifier is a bit strange. I would argue it's not ncessary required we can still write ~ []
gkellogg: A [] now means bnode property list
gkellogg: If we allow empty annotation blocks, it's also a way to avoid the empty ~
<gtw> I believe per the current Turtle draft spec, [] would be valid per the reifier rule: `reifier::='~' (iri | BlankNode)?` (via BlankNode)
AndyS: I think it's a bit confusing because it would be the only place where you can have [] but not [ propertyObjectList ]
ora: If we confuse users it's not going to lead to anything good
ora: We have this think with multiple reifiers and annotations. Is it really relevant?
ora: I don't want for people to start to write things and getting it wrong
<niklasl> Pro/con: <s> :p <o> ~ [ :date "2024" ] . # Pro: Regularity, same syntax for bnodes. Con: may be odd in combination with the naming-and-describing pairing mechanism.
ora: Syntax discussions are often more difficult semantic discussions
<niklasl> +1 for syntax being more difficult (also: "there is only syntax")
ora: It would be nice if we can break this up into a series of decisions
ora: would be nice if somebody take the trouble to figure out which decisions we have to make, we would have examples of the variants
pchampin: if we keep "<<" we need to keep it consistent with what people expect from the CG
tl: << has been used also for asserted things
tl: what part of history do we refer to when we talk about user assumptions?
<pchampin> q.
pchampin: To be clear I said "if we keep" the <<, getting ride of it alltogether is a way to solve the problem
gkellogg: It would be nice to make a decision, everything depends on it
ora: it's unfortunate that the syntax PR has been opened for such a long time with not enough attention
ora: People often take tiny interest on syntax, way less than it is warenteed
ora: I am open to suggestions how to do this
AndyS: we should take this offline
ora: agree we do this offline, in a way we ended up in a place I did not wanted to end, fighting over these things
ora: I suggest chairs will pick this up and will go from there
<pfps> which PR?
<pchampin> w3c/
pchampin: In the interest of splitting into multiple decisions, I think we can bundle the brackets for triple term, unasserted triples and annotations
Addressing SPARQL EXISTS errata 4
ora: Are there people fine with the current syntax?
ora: In any case, chairs will discuss this, let's move on
AndyS: [about SPARQL EXISTS] There are two proposals
AndyS: 1. substitution based on various existing errata
AndyS: 2. an other one based on ANTIJOIN. We already have MINUS. Except the behavior with disjoin domain. But outside of it it's ANTIJOIN
AndyS: On an other note, there are other things that might go to SPARQL like LATERAL that can be based on substitution. And pure form of anti join and semi join
AndyS: It's a possibility to move these additions (LATERAL, anti join...) to sparql dev
pchampin: we would add more subtly differences between operators like FILTER NOT EXISTS vs MINUS
pchampin: Your point of having multiple ways might create problems
ora: SPARQL spec spends a bit of time presenting this difference
AndyS: It was quite contentious in SPARQL 1.1
<pchampin> I'm more than happy to let the editors decide on that
AndyS: I am not aware of any outgoing opinion, I think it ends up to a choice on which way to go
tl: is it related to triple terms in any way of is it a SPARQL errata
AndyS: it has nothing to do with triple terms
tl: what is the criteria of SPARQL errata to discuss now?
tl: it's a central issue, is that the argument?
pfps: There are a bunch of problems with SPARQL, the ones with EXIST are the biggies
pfps: They end up splitting the SPARQL implementation space
pfps: The decision that has to be made is to move SPARQL EXIST toward a more database-like implementation and keep it more consistent with the existing
AndyS: The current implementation is present in SQL with correlated subqueries
pfps: if you use the semi/anti join interepretation of EXISTS you change SPARQL more than the other option
pfps: In the end people who will see and understand the differences are very few
ora: I would like to know preferences
AndyS: My preference is for substitution and applying errata (option 1)
pfps: I don't have much of a horse in this race
pfps: Idealy I would love to get more SPARQL developers on board
ora: we could talk outside of the group
ktk: I reached out to stardog but not got an input
gtw: I am not sure much value to reach out to more developers. sparql-dev has been opened for a long time
<pchampin> Tpt: I have a signicant preference for option 1; option 2 is basically equivalent to MINUS
pfps: One way to check the issue would be to pull some tests
<pfps> which PR?
<gkellogg> w3c/
<gb> Issue 42 tests to document current definition of EXISTS in SPARQL (by pfps) [SPARQL]
<gkellogg> w3c/
<gb> CLOSED Pull Request 43 Add tests to document current definition of EXISTS (by pfps)
ora: Whatever solutions we pick, someone will ask why we pick it
AndyS: picking sustitution breaks the least queries
ora: That seems to me a as good reason as any, let's make a decision
tl: I would like to ask james about it
ora: Let's vote on it next Thursday
ora: Let's do it
Define an interpretation of Triple Terms 5
niklasl: I propose to use the rdf:subject/predicate/object properties for the interpetation
niklasl: This might not good to entail old reification from triple terms
<Zakim> pfps, you wanted to ask how this relates to the semantics from Enrico?
<niklasl> w3c/
<gb> Issue 27 Integrating different ontology designs through entailment upon triple terms (by niklasl) [use case]
<pfps> Where are the semantics from Enrico, by the way?
ora: If we need some clarification on this, does it means we differ this one until Enrico shows up?
pchampin: Does this point to a specific use case or is this a nice to have,
<niklasl> https://
niklasl: there are use cases I defined previously
AndyS: This seems to relate to the discussion around unstar
AndyS: Done this way I don't see how we can add multiple triples to the same reifier
tl: I have developed in a github issue multiple variants and they are all many-to-many
one is RDF-vocabulary based
<niklasl> Here is a comment on the unstarring issue I made yesterday w3c/
<gb> Issue 114 Un-star operation to support RDF Dataset Canonicalization? (by niklasl) [needs discussion] [discuss-f2f]
ora: I don't think we can reach a concensus here, is it a good discussion topic for next week after voting?
<Zakim> tl, you wanted to ask about when rdfs:states will be discussed
<gkellogg> JSON-LD-star slides – https://
<AndyS> +1 to having the JSON-LD presentation in a focused meeting.
ora: Thank you everybody