Re: unstar algorithm and upcoming the RDF Concept CR

> On 16. May 2025, at 17:03, Pierre-Antoine Champin <pierre-antoine@w3.org> wrote:
> 
> Dear all,
> 
> yesterday's conversation about the basic profile and the "unstar"/"classicize" algorithm was very interesting. However, I'm concerned that it may further delay the publication of RDF Concepts as a Candidate Recommendation.
> 
> From the discussion we had (plus some private conversations), I have the feeling that different people have different use-cases / motivations for this "unstar" mapping, which means that we are pulling in slightly different directions. Maybe no single mapping can satisfy them all. Maybe one given mapping could, but finding it will still take us a lot of time...
> 
I guess you are right about pulling in different directions. IIUC there are 2 directions:

A) triple term 2 basic
B) reification 2 basic

A is defined in RDF 1.2 Concepts to enable describing triple terms with basic triples.
B would rather serve to clarify how the new mechanism relates to old-style reification.

IMHO aspect B is of more immediate importance, but I also see the benefit of A e.g. to enable OWL reasoning over triple terms (IIUC). I agree that maybe there need to be two separate solutions.
> My preference at this point would be to extract the current "classicize" mapping into a separate note (it is currently a non-normative section anyway), carry on with the publication of RDF Concepts as a CR, and continue this discussion in parallel.
> 
But there is a risk that people will ask for B to better understand the new mechanism, or that the lack of B (or A) will lead to misconceptions that are harder to correct later once they are "out there".

I’d rather argue for more discussion on this issue, or maybe even explicitly concentrate on this issue, before publishing CRs.

Best,
Thomas
> Having the unstar mapping in a separate document might also help prevent a confusion that I think I perceived yesterday, about the role of version=1.2-basic in content-negotiation. Some people may think that, if a client requests RDF 1.2 basic and the server contains RDF 1.2 full, the only acceptable response would be to transform the data via "unstar".
> I would disagree with that. Other valid options for the server include, in my opinion:
> - respond with 406 Not Acceptable
> - respond with RDF 1.2 Full, with the appropriate version marker
> - apply an ad-hoc conversion of its data into RDF 1.2 Basic
> 
> best
> 
> 
>