Re: unstar algorithm and upcoming the RDF Concept CR

On 16/05/2025 16:03, Pierre-Antoine Champin 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...
> 
> 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.

That seems like a reasonable way to go.

For a non-normative feature, it is already quite a large slice of the 
document and it's not finished yet.

> 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

I agree. This is about how content negotiation (generally) handles such 
a situation. Handling is often in an RDF-agnostic application/HTTP 
framework so mandating, or strongly indicating, behavior is cutting 
across levels.

     Andy

Received on Monday, 19 May 2025 10:31:10 UTC