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

Re: Feature At Risk

From: Benjamin Young <byoung@bigbluehat.com>
Date: Thu, 4 Jun 2020 18:18:46 +0000
To: Leonard Rosenthol <lrosenth@adobe.com>, Ivan Herman <ivan@w3.org>
CC: Gregg Kellogg <gregg@greggkellogg.net>, Benjamin Young <byoung2@wiley.com>, W3C JSON-LD Working Group <public-json-ld-wg@w3.org>
Message-ID: <BN7PR06MB4049AD14C5FE4D6E6D5E0602B2890@BN7PR06MB4049.namprd06.prod.outlook.com>
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<mailto: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<mailto:byoung@bigbluehat.com>>
Date: Wednesday, June 3, 2020 at 3:41 PM
To: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>, Gregg Kellogg <gregg@greggkellogg.net<mailto:gregg@greggkellogg.net>>, Benjamin Young <byoung2@wiley.com<mailto:byoung2@wiley.com>>
Cc: W3C JSON-LD Working Group <public-json-ld-wg@w3.org<mailto:public-json-ld-wg@w3.org>>
Subject: Re: Feature At Risk
Resent-From: <public-json-ld-wg@w3.org<mailto: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<mailto:ivan@w3.org>>
Sent: Wednesday, June 3, 2020 2:47 PM
To: Gregg Kellogg <gregg@greggkellogg.net<mailto:gregg@greggkellogg.net>>; Benjamin Young <byoung2@wiley.com<mailto:byoung2@wiley.com>>
Cc: W3C JSON-LD Working Group <public-json-ld-wg@w3.org<mailto: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<mailto: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<mailto: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 Thursday, 4 June 2020 18:19:04 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 4 June 2020 18:19:05 UTC