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# <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
>     xmlns:dc="http://purl.org/dc/elements/1.1/ <http://purl.org/dc/elements/1.1/>"
>     xmlns:xmp="http://ns.adobe.com/xap/1.0 <http://ns.adobe.com/xap/1.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/ <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/ <http://purl.org/dc/elements/1.1/>",
>         "xmp": "http://ns.adobe.com/xap/1.0/ <http://ns.adobe.com/xap/1.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/ <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%7Cbc6266c55b2947453dcf08d807f61192%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268100742390974&sdata=q5bmf%2Fs2fvjDWFkUR%2BdOVdgtarvEBTM%2Bq4Dh0G%2FJASo%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%7Cbc6266c55b2947453dcf08d807f61192%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268100742400969&sdata=06ot5B1AWvyXjmboFDa0%2F2hpTUCMBrhrHMjXUb0RO1k%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%7Cbc6266c55b2947453dcf08d807f61192%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268100742400969&sdata=81LJjPLjW2F3FeQnM6q1vv%2BgQK3%2F0AeBoD9FSEeVtPo%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%7Cbc6266c55b2947453dcf08d807f61192%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268100742410965&sdata=ftsx2pIzKz4SEkw6ZJzJdlS8RbhNs2fHxskVD4eRT7E%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%7Cbc6266c55b2947453dcf08d807f61192%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637268100742420961&sdata=VEWlfFHu2hcipAA7uEJVZxkJlHCoWeos4a9rsdNZH8M%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/
mobile: +33 6 52 46 00 43
ORCID ID: https://orcid.org/0000-0003-0782-2704

Received on Thursday, 4 June 2020 07:00:45 UTC