Re: WebID default serialization for WebID 2.x

Hi Jonas,

a question: I am having trouble finding the current spec. Also I can not 
find anything about NetID. See more inline.

On 21.01.22 17:49, Jonas Smedegaard wrote:
> Quoting Sebastian Hellmann (2022-01-21 17:29:46)
>> I would argue for a more clear definition of what the webID publisher
>> should/must provide, simply to prevent wiggle space.
> So would you find it acceptable that the WebID spec states that
> publishers SHOULD provide JSON-LD serialization of the RDF data (and
> consumers SHOULD be capable of parsing JSON-LD)?
>
> ...since that is the position held by (at least) Kingsley Idehen and
> Aaron Coburn and me.

That is not enough in my opinion and I am picking up some points from 
Aaron's email. JSON-LD is a moving target. My point is maybe not making 
JSON-LD default/mandatory, but to make it mandatory that JSON-LD does 
not become a pain for "builders" (see Kingsley's mail).

1. although there is names like compact/expanded/flattened , I am 
missing the particular name for the JSON-LD serialization that has the 
context made in a way that it potentially suppresses @value and @type, 
i.e. the JSON-like JSON-LD that has "key" : "value" and not "key" : 
{"@value":"value"} . Also no URIs in "key" . Whenever I find schema.org 
snippets in HTML, they seem to follow this pattern, see e.g. curl 
https://www.imdb.com/name/nm0000313/ | grep schema.org -C  10

Note the missing '/' at the end of "@context":"http://schema.org" . So I 
am asking for a serialization that is not well described by either 
compact/expanded/flattened  .

2.  I have the feeling that some parsers can not re-nest objects back 
into compact, e.g. if you have "foaf:knows" : 
[{"@id":"http://someone.org/#this" },{...}] , so parsing and serializing 
in compact will not give you back the format in 1. Hence "flatten" might 
the more consistent option here.

3. datatypes can be a serious data quality problem. Right now, you run 
into interoperability issues between using "Peter"@en, "Peter" and 
"Peter"^^xsd:string (RDF 1.0 vs 1.1.) . So any RDF spec should come with 
extensive SHACL tests to reduce heterogeneity.

4. The previous point also factors into the JSON-LD context:

"license":{
       "@context":{
          "@base":null
       },
       "@id":"dct:license",
       "@type":"@id"
    },

"@type":"@id" -> causes "value" to be interpreted as URI, i.e. producing 
<http://example.org/> in Turtle/NT around it and not "http:example.org/"

"@base":null -> prevents the faulty addition of base prefix to strings 
that are obviously not meant to be a URI, e.g. "CC-BY" otherwise becomes 
<https://json-ld.org/playground/CC-BY> Also filing this under datatype 
data quality issues.


schema.org manages it quite nicely. Yet, I have not seen other projects 
being able to reproduce this.

-- Sebastian


>   - Jonas
>