Re: JSON-LD 1.0 - "superseded" UI on site is overly harsh and pushy

> On 7 May 2021, at 10:42, Dan Brickley <danbri@google.com> wrote:
> 
> 
> 
> On Fri, 7 May 2021, 07:44 Ivan Herman, <ivan@w3.org <mailto:ivan@w3.org>> wrote:
> Dan,
> 
> the presentation of 
> 
> https://www.w3.org/TR/2014/REC-json-ld-20140116/ <https://www.w3.org/TR/2014/REC-json-ld-20140116/>
> https://www.w3.org/TR/2014/REC-json-ld-api-20140116/ <https://www.w3.org/TR/2014/REC-json-ld-api-20140116/>
> 
> has now changed. It displays the fact that the specification is superseded but, otherwise, it is exactly the same as before.
> 
> Thanks, that is awesome! I appreciate you getting this fixed and I think it helps w3c by making its classic works citeable.
> 
> 
> I hope this settles this issue
> 
> I may send a suggestion to the Process doc team about their use of the word "abandoned", but I can follow up there directly. As far as making JSON-LD 1.0 citable again we are all good. Thanks again :)
> 

You are welcome!

Cheers

Ivan


> Dan
> 
> 
> Cheers
> 
> Ivan
> 
>> On 27 Apr 2021, at 15:03, Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>> wrote:
>> 
>> 
>> 
>>> On 27 Apr 2021, at 14:40, Dan Brickley <danbri@google.com <mailto:danbri@google.com>> wrote:
>>> 
>>> 
>>> Thanks all. I think there's something positive that could be done here, is this something you could raise internally with your W3C team colleagues?
>> 
>> You did raise it, Dan :-)
>> 
>> We are looking into this. As usual, this is not something that could be done in one day…
>> 
>> In the meantime, the "official", albeit superseded 1.0 spec is here:
>> 
>> https://www.w3.org/TR/2020/SPSD-json-ld-20201103/ <https://www.w3.org/TR/2020/SPSD-json-ld-20201103/>
>> 
>> that can be used without further ado by the developers.
>> 
>> Ivan
>> 
>> 
>>> 
>>> On Eric's proposal - would this change the process i.e. https://www.w3.org/2020/Process-20200915/#rec-rescind <https://www.w3.org/2020/Process-20200915/#rec-rescind>  or just the UI on w3.org <http://w3.org/>? I am assuming the latter.
>>> 
>>> We could say 1.0 is superseded by 1.1, while being more tolerant in the UI of the idea that people might want to refer authoritatively (and without upselling to superseding vresions) to the earlier stable standards they've implemented against.
>>> 
>>> Goonlessly,
>>> 
>>> Dan
>>> 
>>> On Tue, 27 Apr 2021 at 13:04, Eric Prud'hommeaux <eric@w3.org <mailto:eric@w3.org>> wrote:
>>> The HL7 FHIR specifications, e.g.
>>>   http://hl7.org/fhir/2021May/ <http://hl7.org/fhir/2021May/>
>>> include link to a directory:
>>>   <a href="http://hl7.org/fhir/directory.html <http://hl7.org/fhir/directory.html>">Directory of published versions</a>
>>> 
>>> The linked page is pretty populated because it includes all drafts. We tend to navigate to previous version links when we care about drafts so we'd have only a couple rows.
>>> 
>>> PROPOSAL: ask W3M to include a list of published RECs directly in the front matter replacing the current message about being a relic of bygone technology. This comm problem isn't limited to JSON-LD.
>>> 
>>> I believe this optimizes both the message that this is a published standard and that there are other versions when you're ready to switch to them.
>>> 
>>> There are a couple practical variants on this:
>>> 
>>> 1. full list of all RECs visible on each REC. Everything behind the current version would be redundant against the <Previous versions> link. Maybe the biggest list would be XML which has five editions.
>>> 
>>> 2. list of all later RECs visible on each REC. Only XML first edition would have links to all four future editions.
>>> 
>>> Another parameter to play with is rather to apply it retroactively or just to future docs (and json-ld 1.0, so danbri doesn't send his google goons after me).
>>> 
>>> 
>>> 
>>> On Mon, Apr 26, 2021 at 04:07:42PM -0700, Gregg Kellogg wrote:
>>> > I’m certainly fine with tweaking the statements on the 1.0 specs, if we can. I believe the thought was that, as the 1.1 specs include everything from 1.0, that they were current, but that shouldn’t imply that the 1.0 specs are inappropriate to cite. 
>>> > 
>>> > Gregg Kellogg
>>> > 
>>> > Sent from my iPad
>>> > 
>>> > > On Apr 26, 2021, at 11:58 AM, Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>> wrote:
>>> > > 
>>> > > On 4/26/21 2:40 PM, Dan Brickley wrote:
>>> > >> My main concern here is with the ability to document Schema.org <http://schema.org/> by saying
>>> > >> "For use in search engines, Schema.org <http://schema.org/> can be written in JSON-LD 1.0" and
>>> > >> having something reliable to point to. Maybe sometime it'll be possible to
>>> > >> say that about 1.1 too. Should we be looking at requesting the superseded
>>> > >> status to be restored, or could the popup warning shown on rescinded
>>> > >> specifications be made less pushy and upselly?
>>> > > 
>>> > > For what it's worth, I agree with Dan and share his concerns regarding
>>> > > messaging to his community of interest.
>>> > > 
>>> > > Perhaps a sticky footer, placed at the bottom of the page, in green/orange,
>>> > > that says: "There is a newer version of this specification. For the latest
>>> > > version please look at: ..."?
>>> > > 
>>> > > -- manu
>>> > > 
>>> > > -- 
>>> > > Manu Sporny - https://www.linkedin.com/in/manusporny/ <https://www.linkedin.com/in/manusporny/>
>>> > > Founder/CEO - Digital Bazaar, Inc.
>>> > > blog: Veres One Decentralized Identifier Blockchain Launches
>>> > > https://tinyurl.com/veres-one-launches <https://tinyurl.com/veres-one-launches>
>>> > > 
>>> > > 
>>> > 
>>> 
>>> 
>> 
>> 
>> ----
>> Ivan Herman, W3C 
>> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
>> mobile: +33 6 52 46 00 43
>> ORCID ID: https://orcid.org/0000-0003-0782-2704 <https://orcid.org/0000-0003-0782-2704>
> 
> ----
> Ivan Herman, W3C 
> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
> mobile: +33 6 52 46 00 43
> ORCID ID: https://orcid.org/0000-0003-0782-2704 <https://orcid.org/0000-0003-0782-2704>
> 


----
Ivan Herman, W3C 
Home: http://www.w3.org/People/Ivan/
mobile: +33 6 52 46 00 43
ORCID ID: https://orcid.org/0000-0003-0782-2704