Re: RDFa + JSON-LD

As someone who has spent far too much of the past 40 years developing software and far too little homebrewing wine, I can tell you a few practical considerations that I'd want clarified.

First, are we going to have a software standards group, akin to POSIX, that defines and maintains a set of well-known APIs and their semantics on the software side of things? People love to roll their own, but it does impair testing and integrating is a serious problem. The RDF side has been sorted, but it's only half the problem.

I'll leave the question of whether sanity checkers prohibit impossible unification of RDF graphs or unify them to the greatest extent that isn't impossible to such a group's defining of semantics.

Second, do we want the logic behind the tools to be provably correct (regardless of whether the tools are ever tested to that degree) or is it sufficient to say that RDF complexities are understood and correctness is purely an implementation detail?

If the logic is provably correct, then toolmakers can be handed a universal conformance test that must be passed by any tool if the tool is to give correct answers when answers are given. It wouldn't mean a program was bug-free, it just means that all failures fail safe.

In theory, that's very nice and is even semi-orthodox in places. In practice, it's sometimes more important to go with the flow and deal with issues as they turn up.

Knowing the answers to those will help in getting tools out there. Protege is nice, but is only the equivalent of Erwin for databases. There needs to be quite a lot more.

Jonathan Day

On 23 January 2017, at 19:21, Dan Brickley <danbri@google.com> wrote:

Yes, what Pat says. With bells on. We already have a mountain of specs
that legitimize the idea of extracting RDF graphs from various sources
and explaining how they can be merged, or kept separately, or
manipulated, queried etc etc in countless ways. Please, no more specs
for a while! In October I'll have been involved with this lovable
circus for 20 years. If this is not now the time for application and
toolmakers to figure out a few practical details, then it will never
be that time. We have all the specs we need for a good while, I hope.

Dan

p.s. regarding Google's parsers, I have looked into this and filed a
bug internally. It is a shortcoming or quirk in our implementation, I
think it fair to say. The non-merging behaviour across
json-ld/rdfa/microdata at Google is purely an engineering issue,
nothing to do with what we felt the W3C specs forbade or encouraged.

On 23 January 2017 at 04:28, Pat Hayes <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> wrote:
>
>
> On 21 Jan 2017, at 02:14, Adam Sobieski <adamsobieski@hotmail.com> wrote:
>
> Ivan,
>
> Thank you. In addition to the major parsers and online test suites (e.g.
> http://linter.structured-data.org ,
> 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). “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) 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
> Sent: ‎Friday‎, ‎January‎ ‎20‎, ‎2017 ‎10‎:‎55‎ ‎AM
> To: Adam Sobieski
> Cc: public-rdfa@w3.org, 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> 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/ .
>
>
> <html>
>   <head>
>     <script type="application/ld+json">
> [{"@id": "2", "http://schema.org/supports": { "@id": "1" }},
>  {"@id": "3", "http://schema.org/supports": { "@id": "1" }},
>  {"@id": "4", "http://schema.org/supports": { "@id": "1" }}]
>    </script>
>   </head>
>   <body vocab="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/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704

>
>
>
> ----
> Ivan Herman, W3C
> Digital Publishing Technical Lead
> Home: http://www.w3.org/People/Ivan/

> mobile: +31-641044153
> ORCID ID: 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       http://www.ihmc.us/users/phayes

>
>
>
>
>

Received on Tuesday, 24 January 2017 16:05:41 UTC