Re: RDFa + JSON-LD

> On Jan 23, 2017, at 2:56 AM, Stian Soiland-Reyes <soiland-reyes@manchester.ac.uk> wrote:
> 
> On Sun, 22 Jan 2017 22:28:47 -0600, Pat Hayes <phayes@ihmc.us> wrote:
>> I may not be following this discussion properly, but surely it was always
>> part of the RDF vision, from the beginning, that RDF content, ie RDF graphs,
>> from various sources can be combined and used in reasoning. (If not, what is
>> the point of the entire semantic web vision?) So it seems to me to be a
>> reasonable extrapolation that if AAA and BBB are two surface syntaxes *for
>> describing RDF graphs*, then the fact that they are different surface syntax
>> should not be interpreted as carrying the implication that the RDF content
>> they encode should not be combined into a single RDF graph (however that
>> graph is encoded.) The combination RDFa+JSON-LD reads to me as just a dialect
>> for RDF+RDF. 

This comes up in real-world search engine usage when an HTML page contains both Microdata, RDFa and JSON-LD, which is actually quite common. I’ve long advocated that this use is perfectly reasonable and should be interpreted as supplementing each other to create a single dataset. My own RDFa parser also looks for Microdata, RDF/XML, and script elements with a @type which is associated with a loaded RDF Reader, such as application/ld+json or text/turtle. All data is loaded into a common dataset.

> I think the main questions in this situation are:
> 
> 1) Do the 'subdocuments' (each RDF block) have to be semantically
> consistent? 

This is not an RDF-layer consideration, but whenever multiple (or even a single) RDF graphs are loaded there may be semantic inconsistency. At the parsing level, it’s just triples/quads.

> 2) Can blank node identifiers be shared across RDF blocks and syntaxes?

MUST NOT, I would say, as the scope of a Blank Node is limited to the document, which I take to be scoped to the intersection of the document and the serialization format.

> I think as HTML as a container of multiple RDF representations has
> not not been specified, the safest would be to assume each block is a separate
> RDF subdocument (parsed separately), and do not share blank node identifiers.
> 
> (you can easily imagine RDFa content and JSON-LD content being generated
> through quite different code bases and therefore might accidentally share bnode
> identifiers)
> 
> 
> However all of these would have the same document URI as the base URI - and
> be from the same authority (usually the base URI), so it would be weird if they
> were NOT semantically consistent. So I would say they should be semantically
> consistent and thus mergable to a single graph - given that you avoid bnode
> overlap when merging.  
> 
> This is equivalent to retrieving the same URI with different content
> negotiation, which should yield semantically consistent (if not the same)
> statements.
> 
> 
> I think RDFa+JSON-LD should be the same as JSON-LD+JSON-LD, as each JSON-LD
> block must be parsed separately (eg. they can't share @context) - however RDFa
> is a single resource across the whole HTML document (but not inside iframes).
> 
> 
> 
> So my view is that these 3 blocks each describe *different* RDF resources
> (unless told otherwise through sameAs etc):
> 
>    <html><body>
>    <script type="application/ld+json">
>        { "@id": "_:b1",
>          "@type": "http://schema.org/Person",
>          "http://schema.org/name": "Jamie Oliver" }      
>    </script>
> 
>      <div vocab="http://schema.org/">
>        <p typeof="Book" about="_:b1">The 
>          <strong property="name">Jamie Oliver</strong> biography.</p>
>      </div>
> 
>      <script type="application/ld+json">
>        { "@id": "_:b1",
>          "@type": "http://schema.org/Restaurant",
>          "http://schema.org/name": "Jamie Oliver" }
>      </script>
>    </body>
>    </html>
> 
> 
> (because each _:b1 is parsed separately)

+1

> ..but they should still be semantically consistent (composable in a single
> graph), e.g. not have incompatible types for a resource with the same
> absolute URI.

That’s an authoring consideration, not an issue for tooling, IMHO.

> As JSON-LD can described named and unnamed @graphs these would be similarly
> mergable to a single RDF Dataset, as if loaded from multiple .jsonld files.
> (RDFa does not have a way to do named graphs)

+1

I do think that there is some interoperability that should be clarified, and a specification leading to a recommendation would be useful for the community, but a CG finding would do.

Gregg

> -- 
> Stian Soiland-Reyes
> University of Manchester
> http://www.esciencelab.org.uk/
> http://orcid.org/0000-0001-9842-9718
> 
>

Received on Tuesday, 24 January 2017 00:12:56 UTC