unstar algorithm and upcoming the RDF Concept CR

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.

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