W3C

RDF-star WG biweekly focused meeting

15 May 2025

Attendees

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

Meeting minutes

ora: before we start,
… Adrian and I gave a presentation last week about RDF 1.2 at the Knowledge Graph Conference
… the talk was very well attended, people were forced to listen from the hallway

<ora> https://www.lassila.org/publications/2025/lassila-gschwend-kgc2025.pdf

ora: link to our slides above

naming RDF 1.2 without triple terms 1

pfps: it appears that it has already been decided, and this is our next agenda item.
… there is an official resolution I guess

https://www.w3.org/2023/10/05-rdf-star-minutes#r03

<niklasl> +1

Define RDF 1.2 Basic profile 2

<pchampin> s|subtopic: https://github.com/w3c/rdf-star-wg/issues/135/|

<AndyS> Summary -- w3c/rdf-concepts#70 (comment)

<gb> Issue 70 Define RDF 1.2 Basic profile (by gkellogg) [needs discussion] [spec:enhancement]

ora: AndyS, you have summarized in the issue thread what RDF 1.2 Basic is
… what is the status of rdf:XMLLiteral, rdf:HTML and rdf:JSON in this?

<pfps> The only change for rdf:XMLLiteral and rdf:HTML is that the documents that they pointed to are now recommendations.

<pfps> I don't think that any other change is needed.

<pfps> This means that they are part of RDF, but implementations don't need to include them.

<pfps> rdf:JSON could end up wth the same status.

niklasl: I have been wonder about the relationship between the RDF 1.2 basic profile and the version tags
… not sure we all have the same notion about what the basic profile is for

<pfps> THere is an editorial question - should the description be moved from Concepts to Schema?

niklasl: is it only about specifying what syntaxes are supporting?
… or is it a version of RDF which has no special meaning for propositions? (as defined in semantics)

pchampin: I believe the profile represents a subset of the abstract syntax, which reflects the concrete syntaxes.
… AndyS's summary goes a bit beyond this, but the point is that it represents a syntax without triple terms.
… I think we need to update the Conformance section; arguably, the class and the profile could be separate things, but I think they should be the same thing.

ora: if people in this group are confused, then other people will be even more, and we don't want that

<pfps> +1 to using the same "tag"

ora: we need to make this very straightforwad to understand, to avoid losing our audience

<Dominik_T> +1 to using the same tag too

AndyS: the semantics is not different. There is nothing in the Semantics document that distinguishes between the profiles.
… I could have been clearer in the summary.

<pfps> +1 to RDF 1.2 Basic is just a syntactic limitation - the semantics is the same

enrico: a warning: if we take this definition of the fragment,
… if I have a rdf:reifies b, b becomes an instance of rdfs:Proposition

<pchampin> agreed, and I don't see this as a problem

<pfps> I'm OK with the entailment of rdf(s?):Proposition happening.

enrico: and rdfs:Proposition is an RDF 1.2 specific feature

niklasl: enrico's point covers the strongest part of my concern
… the "unstar" or "classicize" algorithm is used to remove triple terms;
… it may look as redundant with the basic profile
… same for the version markers;
… my understanding was that their role was to signal "my parser can not understand anything beyond 1.1"

ora: are you implying that the profile should not exist;
… instead, people may simply want to stick to RDF 1.1

AZ: if people use rdf:reifies, you have the entailment Enrico mentioned
… but it is not because of the addition of triple terms; it is because the addition of rdf:reifies
… it is easy to add this to existing reasoners
… The goal of RDF 1.2 is not to allow previous implementation to work "out of the box", you still need to add things like rdf:reifies, rdf:Proposition, base dir, etc.

ora: you are saying: we need to make sure that people are not just slapping a 1.2-basic version on their 1.1 impl

AZ: yes

<pfps> +1 to andy

pchampin: The role of unstar/basicify is to encode RDF 1.2 Full into RDF 1.2 Basic.
… It describes a way of encoding graphs with triple terms without using triple terms.
… We could have defined a mapping to RDF 1.1, but we didn't do that.
… I don't see why this is problematic; maybe it needs to be rephrased.

gkellogg: it is not simply about what parsers support or what systems can represent;
… for me it is also about the RDF-CANON canonicalization

ora: just, let's not use the term "basicify"!

<tl> "turned basic"

niklasl: my understanding is that RDF 1.2 basic was RDF 1.2 semantics with RDF 1.1 syntax
… canonicalization does not work with base direction

enrico: it is not enough to kill rdf:reifies and triple terms
… we need to understand the consequences on reasoning of just restricting the syntax.

<pfps> I don't think that Enrico's concern has any implications, but this should be checked.

enrico: Another point: I don't like how the "unstar" algorithm.
… It does not prevent semantics, why should people use it?
… I believe that "unstar" should only unstar the Turtle syntactic sugar.
… This really question why we want to have RDF 1.2 in the first place.

ora: I've heard many people ask "what about old-style reification?"
… we need to have a very clear answer to this question.
… I understand that this is not only a syntactic restriction.

pchampin: I don't understand enrico's concern.

<AndyS> https://www.w3.org/TR/rdf12-semantics/#dfn-rdfs14

enrico: see 3rd rule in appendix A of RDF semantcis

<AndyS> https://www.w3.org/TR/rdf12-semantics/#entailment_rules -- Grdfs14

enrico: this rule generates triple terms

<AndyS> rdfs14 -- only if <<()>> occurs in the data

<doerthe> I also think these rules won't harm

pchampin: but it generates them in the subject position, so that's generalized RDF, so not part of the abstract syntax :)

niklasl: I think the explanations about reification and the relationship to "old-style" reifications are meant to be in RDF-Schema
… I have not progressed on this

<doerthe> depending what you want, I can help you to go through the semantics, Niklas

niklasl: I want to show that "old-style" reification can be isomorphic to new reification with some inference

<niklasl> My explanation/reasoning is also in w3c/rdf-star-wg#152

<gb> Issue 152 Explain how classic RDF reification relates to triple terms and rdf:reifies (by niklasl)

<doerthe> I'll check

ora: niklasl, when do you think we can have this explanation. This would be something we could vote on.

niklasl: I think we can not make "unstar" semantically interoperable, RDF-Schema is too weak.

ora: I think we need a description of what basic is, its relationship with full, and explanations about the unstar algorithm

<niklasl> There is also an rdf:Statement _as a reifier_ in https://www.w3.org/TR/rdf12-primer/#section-turtle-reifier-representation

ora: I'm not so concerned about having a note document ready, but I would like some text that we can vote on
… I'd like to have this in 2 weeks, to continue the discussion.

<niklasl> (specifically https://www.w3.org/TR/rdf12-primer/#example-unnamed-reifier (Example 15) )

enrico: I think we should rather work on mapping triple terms to old style reification and drop unstar
… having two transformation would confus people

ora: +1 to enrico on this

pchampin: The idea of unstar mapping is to have something as simple as possible.
… I agree that if we have a semantics-preserviing mapping, that would be best, but I don't think we can do that with old-style reification.
… I'm all for trying. We didn't try to be semantics preserving, but to have an encoding that would work for C14N.

<niklasl> I have one, but I fear it's too loose: https://github.com/niklasl/owlery/blob/main/classicize.ru

<tl> old-style reification needs an intermediate mechanism to deal with multi-tripleterm propositions

pchampin: This is not needed if there is a more elegant/semantics preserving way, we should do that.
… But, we don't have this at the moment.

niklasl: I pasted a link with the one I've been toying with
… it is based on the fact that if you have a proposition, you have a token about it
… I think what we need is a way to encode RDF 1.2 data into RDF 1.1 concrete syntaxes

enrico: I believe that we can find an entailment preserving (not semantics encoding) encoding only for the syntactic sugar
… that is a strong thing, because we encourage the use of the syntactic sugar

ora: would this make the syntactic sugar we have a syntactic suger for classic reification?

enrico: no; it would not have the same semantics

ora: and this would be using a different vocabulary than the classic reification

enrico: yes

ora: that would be great, but then we still have the question of the old reification

enrico: the answer would be counter examples: things that were confusing with the old way, and are better with the new way

tl: one main difference is the ability to reify multiple triples for one reifier

ora: how do we move forward?
… I like the idea that a basic reasoner could produce the same entailment that a full reasoner?
… Does this address the problem of canonicalization?

enrico: intuitively yes, but the devil is in the details :)

AndyS: canonicalization is merely about the syntax. All it needs is a form of flattening triple terms.

gkellogg: as long as there is a single way of turning triple terms in RDF 1.2 classic, that would work properly
… canonicalization does not require semantic equivalence

<niklasl> :a rdf:reifies <<( :x :p :y )>> .

<niklasl> #= >

<niklasl> :a rdf:reifies _:tt .

<niklasl> _:token rdf:reifies _:tt .

<niklasl> _:token rdf:tokenSubject :x .

<niklasl> _:token rdf:tokenPredicate :p .

<niklasl> _:token rdf:tokenObject :y .

pchampin: my only concern is that then RDF that can not be expressed using the syntactic sugar could *not* be canonicalized
… this is not unreasonable, but I'm not entirely happy with it

ora: we need to document that
… we are out of time.
… There will be a SPARQL TF tomorrow.

<Souri> What is the RDF1.1 equivalent of the following? :r1 rdf:reifies <<( :s1 :p1 <<( :s2 :p2 :o2 )>> )>> .

<niklasl> s/rdf:refifies rdf:refifies/rdf:reifies/

<TallTed> Souri — I suggest raising that question via email

Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

Diagnostics

Succeeded: s/subitem/subtopic/

Failed: s|subtopic: https://github.com/w3c/rdf-star-wg/issues/135/|

Succeeded 3 times: s/refifies/reifies/g

Failed: s/rdf:refifies rdf:refifies/rdf:reifies/

Succeeded 1 times: s/refifies/reifies/g

Succeeded: s|subtopic: https://github.com/w3c/rdf-star-wg/issues/135|

Succeeded 1 times: s|https://github.com/w3c/rdf-star-wg/issues/135 -> Issue 135 naming RDF 1.2 without triple terms (by pfps) [needs discussion]||g

Succeeded: s/rdf:reifies rdf:reifies/rdf:reifies/

All speakers: AndyS, AZ, enrico, gkellogg, niklasl, ora, pchampin, pfps, tl

Active on IRC: AndyS, AZ, doerthe, Dominik_T, eBremer, enrico, gkellogg, gtw, niklasl, olaf, ora, pchampin, pfps, Souri, TallTed, tl, Tpt