- From: Ivan Herman <ivan@w3.org>
- Date: Mon, 23 Jan 2017 10:42:38 +0100
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Adam Sobieski <adamsobieski@hotmail.com>, W3C RDFa Community <public-rdfa@w3.org>, "public-rdf-comments@w3.org" <public-rdf-comments@w3.org>
- Message-Id: <F7F45EDF-3B51-48F8-A496-C4301CD89F36@w3.org>
Hi Pat,
you did not miss any discussion, there were not really any:-) This just came up.
Sure, what you describe is perfectly fine of course. And if the community and the tool providers agree on that, then we are just done.
However… one _might_ consider looking at an HTML+RDFa+JSON-LD+Turtle combination in a slightly different way, namely that this is a complex (and somewhat weird) serialization of _one single graph_, instead of (in this case) three different graphs that are merged at the end. It is weird, but it may be what a lambda user would like to see or would expect. If we look at it this way, then this means that, for example, BNode identifiers refer to the same BNode, regardless of which 'portion' they are in (it so happens that the _:XXX syntax is valid in all three of those!), that namespace declarations put on a, say, <html> element are valid in the JSON-LD part, etc. Similar questions do arise if JSON-LD is also used to encode datasets, or TriG is used in place of Turtle. (RDFa does not have an encoding for datasets.)
I am _not_ saying this is the approach we should be using; to be honest, I do not have any strong opinion. But, in some way or others, having a community agreement on what is to be done may be indeed useful.
Cheers
Ivan
> On 23 Jan 2017, at 05:28, Pat Hayes <phayes@ihmc.us <mailto:phayes@ihmc.us>> wrote:
>
> Ivan
>
> 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.
>
> No?
>
> Pat
>
>> On Jan 21, 2017, at 12:09 AM, Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>> wrote:
>>
>>
>>> On 21 Jan 2017, at 02:14, Adam Sobieski <adamsobieski@hotmail.com <mailto:adamsobieski@hotmail.com>> wrote:
>>>
>>> Ivan,
>>>
>>> Thank you. In addition to the major parsers and online test suites (e.g. http://linter.structured-data.org <http://linter.structured-data.org/> , https://search.google.com/structured-data/testing-tool <https://search.google.com/structured-data/testing-tool>), there are also JavaScript libraries. I noticed that one, Green Turtle, includes tests for combinations of syntaxes or “semantic hybridization” scenarios.
>>>
>>> It so happens that Green Turtle’s author, R. Alexander Miłowski, is a proponent of “semantic hybridization” (http://www.xmlprague.cz/sessions2015/#semhybrid <http://www.xmlprague.cz/sessions2015/#semhybrid>). “JSON-LD and RDFa are being promoted for use on the Web to augment and annotate information. Yet, each format has its optimal use for encoding particular kinds of information.” A publication by R. Alexander Miłowski “describes a hybrid approach where JSON-LD and RDFa can be used together to provide optimal encoding while retaining connections to document locations.” The interested reader can refer to the conference proceedings (http://archive.xmlprague.cz/2015/files/xmlprague-2015-proceedings.pdf <http://archive.xmlprague.cz/2015/files/xmlprague-2015-proceedings.pdf>) for the publication.
>>>
>>> Are there reasons that independent graphs make a sense in terms of design or implementation?
>>>
>>
>> I do not think there was ever some sort of a "plan" to do that. RDFa, embedded JSON-LD, or embedded Turtle "just" appeared as organic growth, without any plans. There was never any group picking this up, pro or con, to make it a systematic specification of some sort.
>>
>> B.t.w., to complete the picture, I would also add microdata to the mix. After all, mdata can also be seen as a (partial) serialization of RDF.
>>
>>> What are the best courses of action for proponents of merging graphs or “semantic hybridization”?
>>
>> With my W3C hat on: the best is to create a Community Group @W3C, having enough people showing interest, write down a full blown (short) specification crossing all the "t"-s, and convince the different implementers, tool providers, etc., to provide the necessary parsers. around such a spec. *If* there is a need to produce a W3C standard around this (which is an 'if') the CG might start lobbying (e.g., via W3C members) to produce on @W3C after this incubation period. (It would probably be a very short-lived, easy WG.)
>>
>> Ivan
>>
>>>
>>> Best regards,
>>> Adam
>>>
>>> From: Ivan Herman <mailto:ivan@w3.org>
>>> Sent: Friday, January 20, 2017 10:55 AM
>>> To: Adam Sobieski <mailto:adamsobieski@hotmail.com>
>>> Cc: public-rdfa@w3.org <mailto:public-rdfa@w3.org>, public-rdf-comments@w3.org <mailto:public-rdf-comments@w3.org>
>>>
>>> Adam,
>>>
>>> afaik, there is no such specification. Put it another way, the RDFa and the embedded JSON-LD contents (or embedded Turtle content, which is also possible) are considered as separate, and independent RDF graphs. Particular tools MAY merge them and treat them as one, but there is no specification for it as far as I know.
>>>
>>> Which also means that your example below would become very much tool specific.
>>>
>>> Cheers
>>>
>>> Ivan
>>>
>>> On 20 Jan 2017, at 01:03, Adam Sobieski <adamsobieski@hotmail.com <mailto:adamsobieski@hotmail.com>> wrote:
>>>
>>> RDFa Community Group,
>>> RDF Working Group,
>>>
>>> Does anybody know whether or where RDFa + JSON-LD scenarios are specified?
>>>
>>> See: RDFa + JSON-LD Examples at https://www.w3.org/community/argumentation/schemas/ <https://www.w3.org/community/argumentation/schemas/> .
>>>
>>>
>>> <html>
>>> <head>
>>> <script type="application/ld+json">
>>> [{"@id": "2", "http://schema.org/supports <http://schema.org/supports>": { "@id": "1" }},
>>> {"@id": "3", "http://schema.org/supports <http://schema.org/supports>": { "@id": "1" }},
>>> {"@id": "4", "http://schema.org/supports <http://schema.org/supports>": { "@id": "1" }}]
>>> </script>
>>> </head>
>>> <body vocab="http://schema.org/ <http://schema.org/>">
>>> <span about="1" typeof="Statement" property="text">Statement 1.</span>
>>> <span about="2" typeof="Statement" property="text">Statement 2.</span>
>>> <span about="3" typeof="Statement" property="text">Statement 3.</span>
>>> <span about="4" typeof="Statement" property="text">Statement 4.</span>
>>> </body>
>>> </html>
>>>
>>>
>>>
>>> Thank you,
>>> Adam Sobieski
>>>
>>>
>>> ----
>>> Ivan Herman, W3C
>>> Digital Publishing Technical Lead
>>> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
>>> mobile: +31-641044153
>>> ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>
>>
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Technical Lead
>> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
>> mobile: +31-641044153
>> ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>
>>
>>
>>
>>
>
> ------------------------------------------------------------
> IHMC (850)434 8903 home
> 40 South Alcaniz St. (850)202 4416 office
> Pensacola (850)202 4440 fax
> FL 32502 (850)291 0667 mobile (preferred)
> phayes@ihmc.us <mailto:phayes@ihmc.us> http://www.ihmc.us/users/phayes <http://www.ihmc.us/users/phayes>
>
>
>
>
>
----
Ivan Herman, W3C
Digital Publishing Technical Lead
Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>
Received on Monday, 23 January 2017 09:42:51 UTC