- From: Pierre-Antoine Champin <pierre-antoine.champin@univ-lyon1.fr>
- Date: Tue, 9 Jun 2020 08:34:52 +0200
- 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>
- Message-ID: <CA+OuRR_TKxRh05JSzZMbmht3EwRtPkRpGKs1goobnY1kpF+c7Q@mail.gmail.com>
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