W3C home > Mailing lists > Public > public-json-ld-wg@w3.org > June 2020

Re: Feature At Risk

From: Pierre-Antoine Champin <pierre-antoine.champin@univ-lyon1.fr>
Date: Tue, 9 Jun 2020 08:34:52 +0200
Message-ID: <CA+OuRR_TKxRh05JSzZMbmht3EwRtPkRpGKs1goobnY1kpF+c7Q@mail.gmail.com>
To: Benjamin Young <byoung@bigbluehat.com>
Cc: Ivan Herman <ivan@w3.org>, Leonard Rosenthol <lrosenth@adobe.com>, Gregg Kellogg <gregg@greggkellogg.net>, Benjamin Young <byoung2@wiley.com>, W3C JSON-LD Working Group <public-json-ld-wg@w3.org>
On Mon, 8 Jun 2020 at 21:46, Benjamin Young <byoung@bigbluehat.com> wrote:

> Hopefully the "at risk" notices (which really don't make sense in a
> published recommendation...) will be seen as a clerical error and (given
> the results of our vote) be sufficient to allow this to not go back through
> an AC review (which would seem to be a bit much given they're voting on the
> exact same effect document...).
>

That would make sense.

Anyway, is there a scenario where keeping "at risk" notices in a PR or REC
would be desirable?
If, as I suspect, the answer is no, wouldn't it make sense that Echidna (or
another mystical beast down the line) detect those and issues a warning?

>
> Please let me know if/when this needs anything else!
>
> Thanks!
> Benjamin
> Co-Chair, W3C JSON-LD WG/CG
>
> --
>
> http://bigbluehat.com/
>
> http://linkedin.com/in/benjaminyoung
> ------------------------------
> *From:* Ivan Herman <ivan@w3.org>
> *Sent:* Thursday, June 4, 2020 2:52 PM
> *To:* Benjamin Young <byoung@bigbluehat.com>
> *Cc:* Leonard Rosenthol <lrosenth@adobe.com>; Gregg Kellogg <
> gregg@greggkellogg.net>; Benjamin Young <byoung2@wiley.com>; W3C JSON-LD
> Working Group <public-json-ld-wg@w3.org>
> *Subject:* Re: Feature At Risk
>
> Benjamin, it is too late for that. At this moment the only thing we can,
> and should, do is to have a WG agreement on removing the "at risk" notes
> from the text. Even for this step we may have to re-contact all AC reps who
> have voted for the PR wether the object the change before we publish the
> Rec. Anything else means we would have to go back in the process steps.
>
> Yes, we should move on.
>
> Ivan
>
> PS btw, the i18n folks have already reviewed this, no reason to go back to
> them: no new issue occurred. As for the RDF community, we went out of our
> way to reach them on the topics.
>
> ——
> Ivan Herman
>
> (Written on my iPad. Excuses for brevity and misspellings...)
>
> On 4 Jun 2020, at 20:19, Benjamin Young <byoung@bigbluehat.com> wrote:
>
> 
> Thanks, Leonard.
>
> It's the proposed approach to the "mapping back" that was considered "at
> risk"--mostly due to the lack of an active/available/authoritative RDF
> "maintenance" group (which would be a great thing to have!).
>
> Due to the lack of that, we've (essentially) added some things to RDF to
> accommodate text direction and (as Ivan said) hooked those into JSON-LD
> (where folks are frequently facing this language/direction need right now).
>
> Ivan, would it make sense to do another "all points bulletin" of some kind
> to get RDF folks (and maybe I18N folks) to give this one last look?
>
> Or should we just remove the at-risk notices (given these sections are
> non-normative) and move along?
>
> I am a bit concerned that this section is non-normative...but (as has been
> said a lot recently...) that ship has probably sailed. ��
>
> Thoughts?
>
> --
>
> http://bigbluehat.com/
>
> http://linkedin.com/in/benjaminyoung
> ------------------------------
> *From:* Leonard Rosenthol <lrosenth@adobe.com>
> *Sent:* Thursday, June 4, 2020 9:08 AM
> *To:* Ivan Herman <ivan@w3.org>
> *Cc:* Benjamin Young <byoung@bigbluehat.com>; Gregg Kellogg <
> gregg@greggkellogg.net>; Benjamin Young <byoung2@wiley.com>; W3C JSON-LD
> Working Group <public-json-ld-wg@w3.org>
> *Subject:* Re: Feature At Risk
>
>
> Yeah, we don’t support direction today (though it would be nice), so it
> wasn’t a concern.  And if we do have a request for it, we can just use the
> JSON=LD version and figure out how to map that back…
>
>
>
> Thanks,
>
> Leonard
>
>
>
> *From: *Ivan Herman <ivan@w3.org>
> *Date: *Thursday, June 4, 2020 at 3:00 AM
> *To: *Leonard Rosenthol <lrosenth@adobe.com>
> *Cc: *Benjamin Young <byoung@bigbluehat.com>, Gregg Kellogg <
> gregg@greggkellogg.net>, Benjamin Young <byoung2@wiley.com>, W3C JSON-LD
> Working Group <public-json-ld-wg@w3.org>
> *Subject: *Re: Feature At Risk
>
>
>
> Hi Leonard,
>
>
>
> TL;DR: I do not think this is a problem, i.e., I believe what you do is
> perfectly fine as is.
>
>
>
> The problem arises when you have a text that is marked with some language
> and/or with a base direction. RDF, alas!, does not have this notion built
> into the system. I do not know whether you have the notion of base
> direction in the generic XMP model but, even if you do, you cannot express
> this in today's RDF (regardless of the serialization format).
>
>
>
> What the JSON-LD 1.1 spec does is:
>
>
>
> - defines some new RDF vocabulary terms to be able to express those extra
> terms in RDF (in general);
>
> - defines some syntactic sugar, a.k.a. JSON-LD keywords, to express that
> case properly
>
>
>
> But those are extras to what was already there before (i.e., the @language
> term that you use) and by no way invalidate them. Hence what you have is
> perfectly fine.
>
>
>
> On 4 Jun 2020, at 01:58, Leonard Rosenthol <lrosenth@adobe.com> wrote:
>
>
>
> I just read over the rdf:language stuff and that’s definitely **not** how
> we are handling RDF->JSON-LD in the case of the new JSON-LD serialization
> of XMP (XML+RDF).   What we did was using `@language` as we believe that is
> the correct model.  Here is an example from the ISO 16684-3 DIS
>
>
>
> Serialized XMP Packet in RDF/XML with xml:lang qualifier
>
> ```
>
> <rdf:RDF
>
>     xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23&data=02%7C01%7Clrosenth%40adobe.com%7Cf3752950e2064c13d25908d80854fbb7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268508405317409&sdata=n7FmqzffR1cR%2B6gNkSeeFGT5STwGT%2BGlmJ9t%2BOWRJwo%3D&reserved=0>
>
>     xmlns:dc="http://purl.org/dc/elements/1.1/
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpurl.org%2Fdc%2Felements%2F1.1%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cf3752950e2064c13d25908d80854fbb7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268508405327401&sdata=mKHB0EefvvHb6XvOjj5Pnf2v5LkI4jaLuFOM%2FbeFmEU%3D&reserved=0>
> "
>
>     xmlns:xmp="http://ns.adobe.com/xap/1.0
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fxap%2F1.0&data=02%7C01%7Clrosenth%40adobe.com%7Cf3752950e2064c13d25908d80854fbb7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268508405327401&sdata=YnJlHF9o7WH2a0%2Fth5h67o5JMJoifCe7qTsAG286dmc%3D&reserved=0>
> /">
>
>     <rdf:Description rdf:about="">
>
>         <dc:source xml:lang="en-us">
>
>             Adobe XMP Specification, April 2010
>
>         </dc:source>
>
>         <xmp:BaseURL rdf:resource="http://www.adobe.com/" xml:lang="en"/>
>
>         <dc:subject xml:lang="en">
>
>             <rdf:Bag>
>
>                     <rdf:li>XMP</rdf:li>
>
>                     <rdf:li>metadata</rdf:li>
>
>                     <rdf:li>ISO standard</rdf:li>
>
>                     <rdf:li xml:lang="fr">Norme internationale de
> l’ISO</rdf:li>
>
>             </rdf:Bag>
>
>         </dc:subject>
>
>     </rdf:Description>
>
> </rdf:RDF>
>
> ```
>
>
>
> Serialized XMP Packet in JSON-LD with “@language” JSON-LD keyword
>
> ```
>
> {
>
>     "@context": {
>
>         "dc": "http://purl.org/dc/elements/1.1/
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpurl.org%2Fdc%2Felements%2F1.1%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cf3752950e2064c13d25908d80854fbb7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268508405337398&sdata=54ps1CecDVetgxn5LohCK1nAmVHXvc0nIm8uyexHAag%3D&reserved=0>
> ",
>
>         "xmp": "http://ns.adobe.com/xap/1.0/
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fxap%2F1.0%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cf3752950e2064c13d25908d80854fbb7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268508405337398&sdata=5H9cgipmPZsEK1YX%2B9VOiNZQ0hiLMnPGMVyOUbKs34c%3D&reserved=0>
> "
>
>     },
>
>     "@id": "",
>
>     "dc:source": {
>
>         "@value": "Adobe XMP Specification, April 2010",
>
>         "@language": "en-us"
>
>     },
>
>     "dc:subject": {
>
>         "@set": [
>
>             "XMP","metadata","ISO standard",
>
>            {
>
>                 "@value": "Norme internationale de l’ISO",
>
>                 "@language": "fr"
>
>             }
>
>         ],
>
>         "@context": {
>
>             "@language": "en-us"
>
>         }
>
>     },
>
>     "xmp:BaseURL": {
>
>         "@id": "http://www.adobe.com/"
>
>     }
>
> }
>
> ```
>
>
>
>
>
> Leonard
>
>
>
> *From: *Benjamin Young <byoung@bigbluehat.com>
> *Date: *Wednesday, June 3, 2020 at 3:41 PM
> *To: *Ivan Herman <ivan@w3.org>, Gregg Kellogg <gregg@greggkellogg.net>,
> Benjamin Young <byoung2@wiley.com>
> *Cc: *W3C JSON-LD Working Group <public-json-ld-wg@w3.org>
> *Subject: *Re: Feature At Risk
> *Resent-From: *<public-json-ld-wg@w3.org>
> *Resent-Date: *Wednesday, June 3, 2020 at 3:40 PM
>
>
>
> It sounds like we just missed un-marking these as "at risk" before we went
> to CR...due to the lack of feedback from RDF folks...
>
>
>
> The implementation reports seem to show several implementations of these
> "at risk" features--so I'd hardly consider them at risk (from a JSON-LD
> implementation perspective) any longer:
>
> https://w3c.github.io/json-ld-api/reports/#Transform-JSON-LD-to-RDF
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fjson-ld-api%2Freports%2F%23Transform-JSON-LD-to-RDF&data=02%7C01%7Clrosenth%40adobe.com%7Cf3752950e2064c13d25908d80854fbb7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268508405347400&sdata=RjcfyNvRs9Jy3DCT%2BYYfGOXWsfbNq6HpzTv3evzaKag%3D&reserved=0>
>
>
>
> Here's the sections with the "at risk" claim:
>
> https://w3c.github.io/json-ld-syntax/#the-i18n-namespace
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fjson-ld-syntax%2F%23the-i18n-namespace&data=02%7C01%7Clrosenth%40adobe.com%7Cf3752950e2064c13d25908d80854fbb7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268508405347400&sdata=Y1V4%2BP9NC3oJTcOZSlV4rTE3c33jL9tzl6H7GrKrw5A%3D&reserved=0>
>
>
> https://w3c.github.io/json-ld-syntax/#the-rdf-compoundliteral-class-and-the-rdf-language-and-rdf-direction-properties
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fjson-ld-syntax%2F%23the-rdf-compoundliteral-class-and-the-rdf-language-and-rdf-direction-properties&data=02%7C01%7Clrosenth%40adobe.com%7Cf3752950e2064c13d25908d80854fbb7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268508405357386&sdata=W8JG2f4Ct8MFCvKRBsDwSzaAy5MvP3%2Bzc8xXsGx%2Bd%2BA%3D&reserved=0>
>
>
>
> We can certainly put this to a vote in hopes of stiring up some feedback.
> Email should be sufficient unless we get lots of feedback.
>
>
>
> Anyone else have thoughts on this at risk feature before we take it to a
> vote?
>
>
>
> Cheers,
>
> Benjamin
>
> Co-Chair, W3C JSON-LD WG/CG
>
>
>
> --
>
> http://bigbluehat.com/
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbigbluehat.com%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cf3752950e2064c13d25908d80854fbb7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268508405357386&sdata=gSn9iPgCPopYOWACGNdhgtljZZK3h0Wnawnir4q4eyc%3D&reserved=0>
>
> http://linkedin.com/in/benjaminyoung
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flinkedin.com%2Fin%2Fbenjaminyoung&data=02%7C01%7Clrosenth%40adobe.com%7Cf3752950e2064c13d25908d80854fbb7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268508405367384&sdata=9txulR9%2BV2I65D4pyh73qfwK%2BEdyOXSnInRNfDS5N2Q%3D&reserved=0>
> ------------------------------
>
> *From:* Ivan Herman <ivan@w3.org>
> *Sent:* Wednesday, June 3, 2020 2:47 PM
> *To:* Gregg Kellogg <gregg@greggkellogg.net>; Benjamin Young <
> byoung2@wiley.com>
> *Cc:* W3C JSON-LD Working Group <public-json-ld-wg@w3.org>
> *Subject:* Re: Feature At Risk
>
>
>
> Ouch.
>
> As far as I can see:
>
> - looking at the implementation report I see that the features have been
> implemented by two independent implementations;
> - we haven't received any pro or con reactions on these features by the
> RDF community.
>
> I believe, also in view of the importance of these features, that this
> means these features, although originally at risk, should be considered as
> final in the documents. Ie, we have an editorial issue to handle when
> publishing the final Rec.
>
> I would propose to have a vote (mail should be fine) to decide on this,
> and I will go back to the Director to get that solved...
>
> Benjamin, wdyt?
>
> Ivan
>
>
> ——
> Ivan Herman
>
> (Written on my iPad. Excuses for brevity and misspellings...)
>
> > On 3 Jun 2020, at 19:21, Gregg Kellogg <gregg@greggkellogg.net> wrote:
> >
> > We have some remaining Feature At Risk issues in Syntax and API; perhaps
> they should have been removed before PR publication, but I wanted to bring
> this up. Does something need to be done before REC, or is it too late? What
> does it mean to have a Feature At Risk in a Recommendation?
> >
> > Syntax:
> >
> > * i18n Namespace - experimental feature
> > * rdf:CompoundLiteral - experimental feature
> >
> > API:
> >
> > * Deserialize JSON-LD to RDF Algorithm: rdfDirection on i18n-datatype
> and compound-literal options
> > * Serialize RDF as JSON-LD Algorithm: rdfDirection on i18n-datatype and
> compound-literal options
> >
> > Gregg Kellogg
> > gregg@greggkellogg.net
> >
> >
>
>
>
>
> ----
> Ivan Herman, W3C
> Home: http://www.w3.org/People/Ivan/
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2FPeople%2FIvan%2F&data=02%7C01%7Clrosenth%40adobe.com%7Cf3752950e2064c13d25908d80854fbb7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268508405367384&sdata=rwDAFbx9VZKKFga2igRwoytKPlDtnLzvjl47El8wLMo%3D&reserved=0>
> mobile: +33 6 52 46 00 43
> ORCID ID: https://orcid.org/0000-0003-0782-2704
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Forcid.org%2F0000-0003-0782-2704&data=02%7C01%7Clrosenth%40adobe.com%7Cf3752950e2064c13d25908d80854fbb7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268508405377375&sdata=AD75G%2FVn5pEw6HfS809ht%2FMlELIyRoSR7%2FPQsGXnqWQ%3D&reserved=0>
>
>
>
>
Received on Tuesday, 9 June 2020 06:35:23 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 9 June 2020 06:35:23 UTC