Add isLitDataset() function

[Vinnl]

New feature description

This will allow applications that explore a Pod without knowing
what type of data they might encounter to determine what fetch
method to use when they have WithResourceInfo.

This method (send a HEAD/GET request without an Accept header, check if the Response type includes the spec-mandated Turtle or JSON-LD) of determining whether a Resource is an RDF serialisation understood by the server was recommended by the specification team: https://gitter.im/solid/specification?at=5ee9067da85de30394194d06

Checklist

• All acceptance criteria are met.
• Relevant documentation, if any, has been written/updated.
• The changelog has been updated, if applicable.
• New functions/types have been exported in index.ts, if applicable.
• Commits in this PR are minimal and have descriptive commit messages.

[NSeydoux]

Aren't application/rdf+xml and RDFa (I don't recall the mime type and I'm on my phone) spec-compliant serializations ?

[acoburn]

application/json+ld => application/ld+json

[acoburn]

@NSeydoux RDFa typically uses just text/html, so it's hard to identify it as an RDF serialization per se. Plus, there are other complications. application/rdf+xml is legit, but I'd recommend against it -- it doesn't support datasets and ... it's XML. Really, though, if you don't have to support RDF+XML, I'd recommend against it.

[NSeydoux]

Oh yeah, I would never encourage anyone to use RDF/XML, it's an awful serialization, but if we fetch a resource from a Pod and it happens to be RDF/XML, we should be able to recognize it as an RDF Resource I guess (maybe display a popup that goes "RDF/XML ? REALLY ?"), and if it is allowed by the spec I don't think there's a way around it.

By the way, I just checked, N3 doesn't support RDF/XML. The current spec being ultra-precise (Linked Data resources (RDF in the form of JSON-LD, Turtle, HTML+RDFa, etc), I suggest we leave RDF/XML alone in the cold and not support it. If detecting RDFa is also not possible based on Content-Type, this conversation is resolved.

[acoburn]

Suggested change

	["text/turtle", "application/json+ld"].includes(contentTypeParts[0]);
	["text/turtle", "application/ld+json"].includes(contentTypeParts[0]);

[Vinnl]

Hmm, I think Michiel said that to me once, but I can't really find it. What I can find is this:

IMPORTANT: a default Content-Type: text/turtle will be used for requests for RDF resources or views (containers) that do not have an Accept header.

So maybe I should just remove the JSON-LD MIME type and just check that it's text/turtle?

[acoburn]

@Vinnl I wouldn't rely on any statement from the old solid-spec repo. The default of text/turtle is true if the backend is a conforming LDP server, but that isn't a strict requirement of the new Solid spec, so I don't think you can rely on that. Personally, I would leave JSON-LD.

[Vinnl]

Thanks @acoburn. But then the follow-up question is: is checking for just Turtle and JSON-LD enough, or is it also allowed for Solid servers to suddenly default to a different representation?

[acoburn]

I really don't think you'll find a default representation that's not Turtle or JSON-LD. At least not by something that claims to be Solid compliant.

[Vinnl]

Perfect! Thanks :)

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/inrupt/lit-pod/bt4shprvz
✅ Preview: https://lit-pod-git-feat-163-is-litdataset.inrupt.vercel.app