PUT RDFa, then GET turtle

[michielbdejong]

After storing an RDFa document it should be retrievable as Turtle or JSON-LD.

Two use cases:

• A page like https://csarven.ca/#i to be an html page, but also to act as my WebID for Solid
• A blog post that's a recipe as an html page, but a Solid app can retrieve it as Turtle to put the ingredients on my shopping list.

[RubenVerborgh]

+1 to the above; such conneg SHOULD be supported.

A more tricky case is PATCH. HTML+RDFa documents MAY be patched by an XML patch or line-based diff (the propose architectural diagram supports it for that very reason). However, if we PATCH such a resource through SPARQL UPDATE, the original HTML structure is lost; we might want to HTTP 415 for such cases.

[TallTed]

@RubenVerborgh - I'd suggest 409 Conflict instead of 415 Unsupported Media Type, because the submitted media type may be fully supported, but not acceptable as a PATCH to the target resource.

To my mind, PATCH should only work when the submission's Content-Type matches the target resource -- or following specific confirmation, a la "Are you sure you want to replace this 100KB Turtle document [which contains many comments, and a specific order of statements] with that 25KB JSON-LD document [which contains no comments, and a different order of statements]?"

When the target resource is actually a Graph in an RDF-store, any RDF type might be acceptable as a PATCH -- though it is debatable whether RDFa should be considered an RDF type, as adding the RDF to a triple-/quad-store loses the surrounding HTML.

When the target is a materialized document in a specific serialization (which might include non-RDF data, such as comments in a Turtle file, or the HTML portion of RDFa), only the same serialization, and probably generally only line-based DIFFs, should be acceptable as a PATCH -- because any other serialization may cause the unintended and unrealized loss of some data in the original.

[dmitrizagidulin]

@TallTed I agree, the handling of comments is a problem, as far as PATCHes and translating between RDF serializations.
I'm not sure what the best solution is for Solid. Maybe we should spell out in the Solid LDP spec which RDF serializations can be patched, and which cannot. Or maybe that's an implementation issue for each server.

[elf-pavlik]

Does it mean that text/html sometimes gets handled as RDFSource and sometimes as Non-RDFSource? Should plain HTML with RDF embedded in script tags also get handled as RDFSource then?

[csarven]

"Just when I thought I was out, they pull me back in."

If a server implementation can't return a Turtle representation of a requested URI eg. expressing a WebID Profile Document, LDP RDFSource, then the implementation is non-conforming with respect to the conformance criteria of those specs. This seems to happen when for instance, HTML, SVG, or MathML documents enter a system, however, they can't be called back out successfully. It has to do with content negotiation failing than the actual serialisation that may be on the filesystem for a given implementation (which is irrelevant any way). From the LDP perspective, RDFa in host languages is an RDFSource (see also http://www.w3.org/TR/ldp/#dfn-linked-data-platform-rdf-source -> https://www.w3.org/TR/rdf11-concepts/#dfn-rdf-source , "any web document that has an RDF-bearing representation may be considered an RDF source"). Aside: LDP non-normatively comments about "non-RDF formats like HTML", but the context is important. When LDP Rec came out, RDFa Rec didn't exist. What LDP spec most likely meant was HTML without RDFa. LDP's normative usage of RDF sources as per RDF 1.1 holds, and so actually there are no conflicts here.

Given that, I would punt this issue over to an implementation and say that "you're doing it wrong" (tm).

Although I don't think it is necessary to couple PUT RDFa and GET Turtle (or other) for a conformance criteria, I am interested in understanding whether it is needed and for RDFa in a host language. Got further thoughts on that?

I prefer to move the discussion on modification/PATCH of RDFa-based resource to separate issue (as it is outside the scope of this issue). It is super interesting and challenging. For now:

PATCH is done on the "resource identified by the Request-URI". So, as I see, Linked Data Patch Format can be extended and be more comprehensive in what and how resources can be modified. In the case here, that's having PATCH with (X)(HT)ML payloads incorporated into the Solid specs alongside SPARQL Update. Just as SPARQL Update is intended to operate on the Requested-URI, we may have to frame something like XML-Patch (or another approach) to be as well - as opposed to strictly on XML documents. It needs further investigation; determining whether something like XML-Patch is suitable to begin with. In the end, how the PATCH was done should not matter on the underlying RDF graph.

If the frame we are operating in is about the RDF graph, the spec doesn't need to - as far as I can see at the moment - preserve the structure of (X)(HT)ML, but that the underlying RDF (encoded in RDFa in the host language) is. That is, an implementation may want to track or be capable of returning the intended or ideal document structure including the RDFa, or come up with its own generic pattern eg. RDFa in an HTML table or unordered list, or in an SVG g etc. Alternatively, respond with 4xx.

[RubenVerborgh]

If a server implementation can't return a Turtle representation of a requested URI […] then the implementation is non-conforming with respect to the conformance criteria of those specs.

Indeed, and this is fine. We cannot expect from servers to convert arbitrary representations into RDF.

We have to draw the line somewhere, or implementing a server will be so complex that no one will do it. I'm not saying where that line should be, but requiring Turtle conversion for JSON-LD, HTML5+RDFa, XML+RDFa, N-Quads, TriG, RDF/XML, and whatever we can think of would be a big requirement.

So as far as I am concerned, I would spec that:

• a server MAY be able to represent a resource originally created from an HTML+RDFa representation as text/turtle

I could support a SHOULD, but likely not a MUST.

[acoburn]

Thinking about this purely from an implementation perspective, I find the feature very interesting, but there are also a lot of complications. I would definitely like to support it, but there are all sorts of edge cases that would need to be considered. @csarven and I have discussed specifically how this could work, and I would like to experiment with those.

If the specification uses MAY, that would give much more "breathing room" for implementations to experiment. SHOULD would be OK, but MUST would be a very high bar.

Just as a note, LDP requires that a conforming server support (at a minimum) both Turtle and JSON-LD.

[csarven]

We cannot expect from servers to convert arbitrary representations into RDF.

The context of the paragraph was RDFSource, not any arbitrary representation into RDF.

The spec doesn't need to over-specify. If anything, if a server accepts text/html, image/svg+xml, I would suggest that it MUST be able to serve it back out as text/turtle or application/ld+json. This is not particularly different than accepting application/ld+json and returning text/turtle when requested, and that's already within LDP.

[RubenVerborgh]

It is different. Parsing HTML5 is significantly more complex. And currently JSON-LD isn’t even a MUST (in all fairness, nothing is yet).

[csarven]

Parsing complexity may be a factor to check and help decide whether a content type is part the ecosystem, but it is not the only or the most important factor. We can't categorically dismiss a content type based on the parsing complexity either, especially when each have fairly well-defined areas of use - IMO, driving decision making.

JSON-LD is a MUST in Linked Data Platform, Web Annotation Protocol, Linked Data Notifications, Activity Pub (if you want the LD take on it),.. of the top of my head from recent specs, as well as some contemporary publishing practices (like JSON-LD in HTML.. but that's a weird case in and itself and we can come back to that discussion later). JSON-LD ought to be a MUST for applicable Solid specs, otherwise it will distance itself from what relatively plays well out there. Similarly, RDFa in common host languages is important if "content" publishing means anything for the Solid ecosystem. If RDFa - parsing at the very least - is not a MUST, there is not a whole point in incorporating HTML, XML Family and so forth. We could dismiss RDFa because it is "too complex", but in reality only shifted the complexity to another location in the system. Again, if a server is willing to accept content types that can potentially include RDFa, why would it disservice by not making the underlying graph serialised as Turtle, JSON-LD.. to consumers?

The Solid specs are not mandating the implementation of RDF parsers; only their use.

If we want to use https://www.w3.org/TR/html-design-principles/#priority-of-constituencies as a rough guideline to orient ourselves (as stated in Culture), this is an excellent timing to apply it, otherwise we can remove that effective immediately.

[RubenVerborgh]

Again, if a server is willing to accept content types that can potentially include RDFa

That’s not an applicable argument, because a Solid server is a file server that will accept any content type for storage. The question is thus not about acceptance, but rather about what conversions MUST be supported.

Some of these can perfectly be optional; the client can do them if needed.

If we want to use https://www.w3.org/TR/html-design-principles/#priority-of-constituencies as a rough guideline to orient ourselves

I agree with the principle, but it unfortunately can be used as an argument for adding many features, so we need to take more factors into account. Ultimately, it’s about the experience the user gets, not about whether something should be in the server or the client.

[csarven]

a Solid server is a file server

That's part of it, but not strictly the only thing a Solid server does. Obviously conversions and modifications happen from the perspective of resources identified at requested URIs.

Needless to say, conversion only happens if 1) possible 2) we want it to. 1 is indeed possible, and I see no particular reason it can/should/must not happen when it is perfectly meaningful and useful to do so. Again, if the conversion possibility to JSON-LD is not a MUST for a Solid server, then it is not an LDP conforming server. Any client application that is able to talk to LDP (and the list of specs I mentioned above) will not be able to via JSON-LD. If there is a perfectly useful graph in HTML, why prevent its reuse? How do you envision human and machine-readable documents to be published and consumed on the Web? Dependency on JavaScript, requires DOM handling under a GUI? Archivable? How accessible exactly? Did anyone actually experiment with that under the Solid paradigm? Well, FWIW, I have. Publishing "web pages" - I'm being as generic as I can be on this one - what drives the Web today. What assurance (if at all) given that a reasonably smooth transition from what exists today to what's arguably semantically richer without bringing a minimal step through RDFa onboard for some use cases?

Aside: I feel that I need to yet again make the case for "why RDFa".. and this is a discussion that I've been personally involved in since at least 2015 in context of Solid. And, after all these years, I have yet to see FWIW anything vaguely equivalent to Web authoring/publishing/consuming applications (along the lines of dokieli - and that's only an argument for a starting point, not how everything should be for Web publishing). If the alternative approaches are great and possible, where are they? I'm not interested in the hypotheticals here. Until that happens, I am arguing from the point of actual publishing and implementation experience... and maybe that can be classified under the "experience the user gets".

The use case of this issue is that, someone with an existing website (let's say non-Solid-based - whatever that means), can't successfully migrate to a Solid based server - unless drastic maneuvers are taken in order to participate. Why? Because what I'm hearing is HTML(+RDFa) is "too complex" and that a Solid server decides to not conform to LDP.. and possible kick itself out of interoping with stuff... for starters.

[csarven]

I'd like to emphasise that so far the discussion revolved around whether conversion from RDFa to Turtle should happen on a server. Another mutually possible option is that clients/applications MUST be able to parse RDFa. The end result is the same in that an RDF graph gets passed around. In order to make use of the original document structure (if available) to some degree - thereby being lossless - I think applications being able to parse RDFa is more important than a server converting to something else - thereby being lossy. There are different set of advantages to RDFa parsing in either direction as you can see. From my own experience, I think both should be in place.

[RubenVerborgh]

Because what I'm hearing is HTML(+RDFa) is "too complex" and that a Solid server decides to not conform to LDP.

No straw man arguments please 🙂

The argument put forward is:

• support for conversions comes at a cost
• hence, let's try to minimize the number of conversions that MUST be implemented
• others are fine through MAY or SHOULD

Again, if the conversion possibility to JSON-LD is not a MUST for a Solid server, then it is not an LDP conforming server.

Conformance to LDP is another matter entirely.
It is not because a server accepts an HTML+RDFa or JSON-LD document, that it MUST consider that document as an LDP RDF Source. The spec says that, if a resource is an LDP RDF Source, then the server must be able to represent it in Turtle.

The inverse is not true: the spec says that "LDP servers MUST provide an RDF representation for LDP-RSs", but not that resources created though any RDF representation must be LDP-RSs.

I feel that I need to yet again make the case for "why RDFa".

I don't think anyone needs to be convinced about that; we understand the utility of RDFa.
Whether all Solid servers MUST therefore support it (so also the Arduino server emitting the temperature in my attic) is something else.

[csarven]

Strawman? You literally said "significantly more complex"!

The argument put forward is:
support for conversions comes at a cost
hence, let's try to minimize the number of conversions that MUST be implemented
others are fine through MAY or SHOULD

Pardon me but I find this line of argument narrow and we need to have a holistic look at the situation. I've given several explanations as to why that's narrow (from distancing itself from interop with other things out there to constituencies..) but you are still dismissing the reasons put forward and want to carry on with your original argument.

I'm happy to come back to this discussion if you like by first agreeing on Use Cases and then we can see which arguments to dismiss them are actually stronger.

Or maybe just explain how you think arbitrary information fragments in human-readable/actionable content can be better handled than non-RDFa. Outline the complexity of that alternative approach and compare. Convince me that is not reinventing or patch work and having more utility than what's available to us right now out of the box. As I've already mentioned, it shifts the complexity elsewhere, doesn't eliminate it.

Conformance to LDP is another matter entirely.
It is not because a server accepts an HTML+RDFa or JSON-LD document, that it MUST consider that document as an LDP RDF Source. The spec says that, if a resource is an LDP RDF Source, then the server must be able to represent it in Turtle.

The inverse is not true: the spec says that "LDP servers MUST provide an RDF representation for LDP-RSs", but not that resources created though any RDF representation must be LDP-RSs.

Hairsplitting. There is no strong reason as to why a system needs to ignore HTML+RDFa, JSON-LD.. as perfectly normal "candidates" for an RDFSource. The minimal assumption and understanding is that, they are in fact RDFSources. It takes a stronger argument to suggest that they are not. So, I'm all ears on that. Moreover, we are not arguing about any arbitrary formats being classified as an RDFSource, but only the obvious candidates.

"Complexity" doesn't hold because the development and use of an RDF parser by a machine just simply doesn't weigh more than the utility. Why should it?

I would add that there are two "complexity" arguments being passed around. One is about the actual parsing of the format and the other is about having a "simpler" agreement on what a server and/or a client should be capable of.

Whether all Solid servers MUST

Because interop. Not going to interop through MAYs, and SHOULDs can be ignored as they are not the fundamental for interop when it comes down to it. Either or both the server or the client has to MUST, otherwise I fail see the point in continuing this discussion.. or bother to build "Web publishing" tools, or failing to take advantage of a class applications that are built on other specs which are relatively at our fingertips. If the requirement is optional/weak, implementations are not expected to do it, and so it defeats the purpose of saying anything about it in the first place.

I think a reasonable position for a server and a client to be in is:

if a server or a client accepts application/ld+json, text/html, image/svg+xml,.. they MUST be able to handle it as an RDFSource (or as something RDF-bearing as per RDF 1.1 Concepts).

I think that actually addresses your concern on "whether all Solid servers..". Given the condition it sets (ie. the if), then the answer is no, not all. If a server/client has no use or interest in working with them, they can ignore the requirement. For everyone else, I think that's a fair expectation and an application of the principle of least astonishment.