W3C

RDF-star WG biweekly focused meeting

27 February 2025

Attendees

Present
AndyS, AZ, Dominik_T, eBremer, fsasaki, gkellogg, gtw, james, ktk, niklasl, olaf, ora, pchampin, pfps, Souri, TallTed, tl
Regrets
enrico
Chair
ora
Scribe
olaf

Meeting minutes

<tl> vscode

<james> protege on occasion

<TallTed> OSDE, The OpenLink Structured Data Editor -- https://osde.openlinksw.com/

ora: First item is the reporting on the survey

<pchampin> https://www.w3.org/2002/09/wbs/139681/2025-rdf-star-tripleterms-subject/results

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://www.w3.org/TR/rdf-plain-literal/ ?

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://www.w3.org/1999/02/22-rdf-syntax-ns#> ; rdfs:label "PlainLiteral" ; rdfs:seeAlso <http://www.w3.org/TR/rdf-plain-literal/> ; rdfs:subClassOf rdfs:Literal .

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://www.w3.org/2003/06/sw-vocab-status/ns#unstable?

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/rdf-star-wg#132

<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/rdf-star-wg#132

<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/rdf-star-wg#131 (comment)

<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.

Summary of action items

  1. pfps to make a PR to remove plainLiteral from semantics

Summary of resolutions

  1. Remove rdf:plainLiteral from Semantics doc and add a change note
  2. Close issue w3c/rdf-star-wg#132
Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

Diagnostics

Succeeded: s/issue/PR

Succeeded: s/(?)/PlainLiteral/

Succeeded: s/That's why we shouldn't allow it./

Succeeded: s/+1 </+1 to pchampin </

Succeeded: s/pi**ed/unsatisfied

All speakers: AndyS, gkellogg, james, ktk, niklasl, ora, pchampin, pfps, tl

Active on IRC: AndyS, AZ, Dominik_T, eBremer, fsasaki, gkellogg, gtw, james, ktk, niklasl, olaf, ora, pchampin, pfps, Souri, TallTed, tl