Require server ability to convert RDFa -> JSON-LD and RDFa -> Turtle?

[michielbdejong]

RDFa support is currently not required, but a lot of Solid server implementations support it already, and it's nice.

Should we start requiring it?

[acoburn]

Define require. Yes, it is nice to have, but there are also a lot of difficulties that arise.

[michielbdejong]

By require I mean SHOULD or MUST. I guess we currently have it as MAY.

[acoburn]

That's not at all what I mean. What are the semantics: What does PUT mean? Can a subsequent GET return Turtle? Can one PATCH to the RDFa document.

[acoburn]

Existing conversation of this has occurred at:

• PUT RDFa, then GET turtle #195
• Required RDF serializations for Solid #45

[michielbdejong]

Ah right. By 'support' I mean the tests we now have skipped in solid-contrib/solid-crud-tests@e2079d1, so RDFa -> Turtle and RDFa -> JSON-LD

[michielbdejong]

I think currently NSS, PSS and CSS do support it, but ESS does not.

[acoburn]

I think currently NSS, PSS and CSS do support it, but ESS does not.

This is not entirely accurate. The key text in the specification is:

When a server creates a resource on HTTP PUT, POST or PATCH requests such that the request’s representation data encodes an RDF document [RDF11-CONCEPTS] (as determined by the Content-Type header)

The question is: does the representation encode an RDF document. What is left undefined is what representations encode an RDF document. Does that mean that RDF/XML MUST be supported? TriG? N-Quads? All of those are also RDF documents. What makes RDFa more required than those other documents? And what if RDFa is encoded as text/html vs application/xhtml+xml? Does that mean a server needs to fully parse all such incoming documents? That is a potential security issue.

At present, the only two RDF serializations that are required by the Solid protocol are Turtle and JSON-LD.

If the specification specifically requires treating RDFa as an RDF document, then the claim above can be made. Until then, it's dubious.

[michielbdejong]

Exactly. So that is what I'm proposing here.

[acoburn]

I am not against such a proposal, but please be very specific in defining what exactly you are proposing.

What, specifically, does it mean to extract RDF from an HTML document? Does that included embedded JSON-LD? MicroFormats? Please define the security issues of performing that type of parsing along with mitigations of those issues.

At what level is support required? MAY? SHOULD? MUST?

And why RDFa and not TriG?

What about other "hosted" RDF representations such as SVG? (or any arbitrary XML serialization, for that matter).

Please note any prior art in this area. I can tell you that there exists no widely available RDFa parser for Java, so please describe how that squares with any proposed requirements.

[TallTed]

a lot of Solid server implementations support [RDFa] already

Define "support".

Compare and contrast their support of RDFa with their support of Turtle and of JSON-LD.

This has been discussed MANY times already...

RDFa is HTML-plus-RDF, HTML embellished with RDF, primary or base media type being HTML.

RDFa is not RDF-plus-HTML, RDF embellished with HTML, primary or base media type being RDF.

In my experience of RDFa documents, it's vanishingly rare for the entire HTML content to be echoed in the RDF. (It's only somewhat less rare for the entire RDF content to be echoed in Turtle or JSON-LD islands, wrapped in <script ... /> elements.)

Treating [HTML+]RDFa documents as RDF documents imposes a great many expectations, including that the server will be able to properly handle all sorts of updates, which the user will not expect to result in loss of non-RDF HTML, but which will result in that loss if the server doesn't understand the full structure of the [HTML+]RDFa document -- and that structural understanding imposes a great deal larger burden on the server and therefore on its developers.

[michielbdejong]

Good arguments, @TallTed. OK, that sounds like way too much trouble with limited benefit.

I agree, let's keep it as a "MAY", as it is now.

We'll take https://github.com/solid/specification/pull/196/files#diff-3c58fc941496320b6f38ff6b9450e86634f2f5bdefb7ca989f62022177bd69f6R287 with a grain of salt, that's to say, yes they must accept such GET requests, but there are no expectations about which of the embedded triples would actually appear in the body of that response.

As such, we can keep our existing "RDFa -> JSON-LD" and "RDFa -> Turtle" tests, so we can inform users that some servers have this additional feature, but remark that it's only a MAY and not very well defined how it should work in practice, so it will be of limited use to Solid apps.

We're adding support for MAY/SHOULD/MUST distinction to our test suite reports, so this is a nice test case for how we would report on a 'MAY'.