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

Re: Feature At Risk

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Thu, 4 Jun 2020 13:08:48 +0000
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>
Message-ID: <58DD8513-6234-417F-A95B-4DADC1128E26@adobe.com>
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 13:09:06 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 4 June 2020 13:09:08 UTC