Meeting minutes
<tl> vscode
<james> protege on occasion
<TallTed> OSDE, The OpenLink Structured Data Editor -- https://
ora: First item is the reporting on the survey
<pchampin> https://
pchampin: link to results
Formal Working Group vote about triple terms in the subject position 1 agendabot]
pchampin: no consensus
… three formal objections on each side
… Our process is that the chairs can take a chairs decision, recording that their is dissent
… 8 persons prefer to forbid triple terms in the subject position, 5 persons prefer to allow it, and 12 (?) are okay with both
… The chairs decision needs to be described carefully, better on the mailing list than here in the call
ora: Yes, we will announce on the mailing list. Interesting situation.
… not unexpected.
ktk: Unfortunately, yes, no consensus.
… BTW, I liked this way of voting (for such difficult things)
james: This GitHub issue on this topic is very long
… it contains argument for both directions
… I request the chairs to take these into account (respond to them) when describing their chairs' decision
ora: yes, sounds reasonable
Remove rdf:plainLiteral from Semantics? 2
ora: This issue was opened by pfps
<pfps> sorry, I'm late
<pfps> one moment to fix audio
<pfps> fixed now
gkellogg: related to that, there is an PR on removing ... PlainLiteral from RDF/XML
<pfps> As I see, there are several options - deprecate, remove and note, ...
gkellogg: when that PR is merged, there is no reference anymore to plainLiteral in the RDF/XML spec
pfps: RDF 1.1 fixed the issue, but plainLiteral remained in the Semantics doc
… question is whether to remove it or to add a deprecation note
… I prefer the latter (depr.note)
AndyS: Remove it and leave a change node.
… because it is just a datatype
pfps: With this rationale, rdf:JSON should go too, because it is also just a datatype
AndyS: but that one is not in RDF-Semantics, right?
pfps: Yes. In this sense it's different.
<ora> PROPOSAL: Remove rdf:plainLiteral from Semantics doc and add a change note
<Dominik_T> +1
<ora> +1
<gkellogg> +1
<AZ> +1
<tl> +1
<olaf> +1
<fsasaki> +1
<ktk> +1
<AndyS> +1
<pfps> +0
<james> +0
<TallTed> +1
<Souri> +1
<pchampin> +1
<gtw> +1
<niklasl> +1
pchampin: Any objection to replacing "remove" by "deprecate"?
<eBremer> +1
pfps: The change note should say that it is removed.
ora: It is at the editors' discretion how to phrase that note.
<niklasl> Removing the URL would be uncool?
gkellogg: Should we and can we remove it from the namespace document?
<niklasl> What's the standing of https://
pfps: I would say we should remove it from the namespace. It is a historical artifact; none is using it.
… The note in the Semantics doc should include saying that it was also removed from the namespace doc.
<niklasl> From the namespace RDF: rdf:PlainLiteral a rdfs:Datatype ; rdfs:comment "The class of plain (i.e. untyped) literal values, as used in RIF and OWL 2" ; rdfs:isDefinedBy <http://
RESOLUTION: Remove rdf:plainLiteral from Semantics doc and add a change note
pchampin: I suggest to record the resolution first.
… response to gkellog that plainLiteral is not in ... (?) but in the RDF file.
niklasl: What pchampin said.
… it would be uncool if the URI disappears
… but a note can be added in the RDF file
<Dominik_T> https://
james: If there is no longer a definition for it, it should be removed from the RDF file such that it doesn't appear in results anymore.
pfps: There is still a definition in a separate document.
<niklasl> +1 to deprecate (even rdf:PlainLiteral owl:deprecated true . )
james: In this case, okay.
ora: action for pfps to take care of implementing this decision
ACTION: pfps to make a PR to remove plainLiteral from semantics
<gb> Created action #147
Turtle Grammar: Collections and blank node property lists in triple terms 3
ora: Next issue came from Dörte, who is not here today.
… What do we think?
<AndyS> << :s :p [ foaf:name "Alice" ; foaf:birthday "1999-04-01" ] >> :src :someGraph
AndyS: My problem with the feature is the example in the chat because
… that one asserts into the graph the triple ... (?) as a side effect.
… The issue for me is the fact that we may have such side effects.
pchampin: Response to AndyS, it depends on how we define the syntax (shorthands)
… but I don't like that
… the fact that there is an ambiguity makes me contra this feature
gkellogg: ... Turtle ... (?)
… Use of collection is even more problematic
… overloading other parsing structures is complicating things
… every triple coming out of that would be reified using the same reifier
<niklasl> +2 to gkellogg
gkellogg: While that is consistent, it is problematic.
james: The question coming up signals that there is an expectation of this feature
… There should be a decision on that which is consistent with what one would expect in NQuads
<Zakim> AndyS, you wanted to response to PA
AndyS: I agree with pchampin's analysis, but Dörte didn't see a problems with the asserted triples
… So, it is two different viewpoints.
<pchampin> which demonstrates that this is highly ambiguous!
ora: I would like to see an example of how one would do it if the list already exists.
… Because the list is a blank node.
… Probably the same issue as if we would have literals that refer to blank nodes.
niklasl: THere are intersting things to explore here.
… but I agree with AndyS and gkellogg
<niklasl> :s :p [ foaf:name "Alice" ; foaf:birthday "1999-04-01" ] {| :src :someGraph |} .
niklasl: I would not like to see support for this notation, because of time
… time constraints
… You can have a name for the whole "chunk"
ora: Is more investigation needed?
<niklasl> defer-next-version ?
ora: Personally, I am still a little confused; in particular of the downstream effects
… Should we table it as something that we may come back to later
gkellogg: Yes, not take it up now. It cannot be removed.
<niklasl> If we keep the current disallowing of [] and () in << ... >>, there is no ambiguity.
ora: I am leaning to disallowing it.
pchampin: As gkellogg pointed out, it is still possible for us or a future WG to come back to it.
… So, should we close the issue or mark it as possible future work?
… Or third option is that someone thinks it is urgent and needs to go into our REC
tl: How can we allow this but not multiple triples?
AndyS: I agree with tl
… We have a different syntax for sets of triples, and this one wouldn't be the one I would start with.
<niklasl> +1, future syntax for "reification blocks" *might* be a thing. (But let's not promise that.)
AndyS: We do already allow one reifier for multiple triples.
… as enrico was eager to have.
<ora> PROPOSAL: Close issue w3c/
<gb> Issue 132 Turtle Grammar: Collections and blank node property lists in triple terms (by doerthe) [needs discussion]
<pchampin> +1
ora: Are you saying that we already have a way to implement this?
<ora> +1
<gkellogg> +1
<niklasl> +1
AndyS: I guess, yes.
<james> +0
<fsasaki> +1
<tl> +0
<Dominik_T> +0.9
<olaf> +1
<AndyS> +1
<eBremer> +1
<gtw> +1
<TallTed> +0
<ktk> +1
<Souri> +1
<AZ> +0
<pfps> +0
RESOLUTION: Close issue w3c/
<gb> Issue 132 Turtle Grammar: Collections and blank node property lists in triple terms (by doerthe) [needs discussion]
ora: Okay, we can close this.
james: I would ask that the authors of the Turtle doc make sure that the readers are aware that there is something in NQuads that cannot be written in Turtle.
<niklasl> In triples. No need for quads.
Streamline Turtle-star syntactic sugar and future-proof it for graphs 4
gkellogg: Can you raise an issue spelling out what you think the problem is.
james: okay
tl: This one is a bit older.
… Two concerns
… One is that the syntax looks bewildering for someone who is not used to it.
… Not very appealing.
… The annotation syntax is also not nice.
… Second, there should be a star * in the syntax
… because that were it comes from.
<pchampin> except that <* ... *> does not work, it can be interpreted as a relative IRI (in some cases)
tl: The other thing is that I am troubled that the annotation syntax uses curly braces
… because they usually have a different meaning in other cases in which it is used.
… We should have re-appearing symbols, if they mean the same thing.
… I propose to use square brackets.
… Third thing, triple terms in subject position.
<AndyS> +1 to pchampin "<* ... *> does not work"
tl: Maybe we (james and I) overdesigned the thing a bit
<niklasl> +1 to pchampin <*:s:p:o*>
tl: Alternative option: if there is an identifier, it is an occurrence; if there is none, it is a triple term
… My hope is to have another discussion about the syntax.
pchampin: One of your arguments was that the current syntax is not ideal,
… to which I agree.
… Yet, it has been around for a number of years.
… A large part of the community has become used to it. Changing it would be disruptive.
… What we have now has been carefully crafted, and works (no conflict with other uses of these characters).
james: The notation that is much clearer and less likely ... as in this case ... would be more beneficial
tl: There are various proposals, not throw out all right away.
… Regarding the argument that it has been around, the meaning of the syntax has changed over time.
… The further we get away from such confusion, the better.
ora: Is there some other problem with the syntax, apart from confusion for users?
tl: The curly braces should remain only for graphs / sets of triples.
… I prefer square brackets with stars instead.
… I don't want to go into the details here.
niklasl: key question is whether we can actually change things.
gkellogg: Grammar design is not trivial.
… We spent months and months finding little issues in the grammar that we have now.
… I don't think the triple term grammar is ugly, in particular because we don't expect them to be used largely.
… The time for making large changes to the syntax is passed. We need to move on; lots to do.
… and Turtle is just one syntax.
<pchampin> +1 to gkellogg: those proposal are great for an alternative syntax (which could also get rid of many other legacy oddities of Turtle)
gkellogg: There will be JSON-LD, etc.
ora: I am also hesitant to start redesigning things.
<AndyS> w3c/
<gb> Issue 131 Streamline Turtle-star syntactic sugar and future-proof it for graphs (by rat10) [needs discussion]
tl: You said we should postpone discussing the syntax.
… I am really unsatisfied if this is the (first and) last time this will be discussed in the meeting,
AndyS: We have decided to use GitHub issues for discussions.
… We really are out of time on this, as many people have mentioned in the issues list.