Re: WebID default serialization for WebID 2.x

On Sat, 22 Jan 2022 at 00:23, Sebastian Hellmann <
hellmann@informatik.uni-leipzig.de> wrote:

> 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"
> <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" <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/> <http://example.org/> in Turtle/NT around it and
> not "http:example.org/" <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>
> <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.
>

Thanks Sebastian.  I favour this JSON approach for a potential future
path.  Perhaps, including aaron's suggestion of a @context, or "plain
JSON".  The actual serialization could be something the group could
discuss.  I do think schema.org has shown the way on this, and it has
adoption on many millions of websites.  I also think the pattern of JSON in
a structured data island is valuable.

And the current webid spec could live on and be used by those already using
it, without breaking code


> -- Sebastian
>
>
>  - Jonas
>
>
>