Add support for RDF*

[rubensworks]

This brings this package up to date with the latest RDF/JS data model spec.

As suggested by @tpluscode, I've made the dependency range of @types/rdf-js as * to avoid future versioning issues. This way we're in line with how DefinitelyTyped handles typings dependencies as well.

\cc @bergos

[tpluscode]

I think that the data factory also needs to be updated. In an esm fork I experimented with RDF* and I figured that dataFactory#quad should ensure that the subject is upgraded to a compliant termType='Quad' structure

Right here I check whether the subject is a quad but without termType:
rdf-esm/data-model@master...rdf-esm:rdf-star#diff-c62ad95856c3c32496eea9c7854ad775R39-R44

And tests are like this:
rdf-esm/data-model@master...rdf-esm:rdf-star#diff-f33e770296d5ce90cf32852e9e73005eR33-R73

[rubensworks]

@tpluscode I like the idea, but wouldn't some kind of dedicated ConvertingDataFactory be better for ensuring this?
For factories where we're certain that quad terms are compliant, this just adds unneeded CPU cycles.

Side-note: quad terms can also occur in the object position. (in generalized RDF even in every position)

[tpluscode]

I'm pretty sure that the RDF* factory should ensure it produces compliant terms. Otherwise you might have unexpected results?

Is there a spec for this? I tried to config what you said but all examples I found for RDF* only used quad term in subject position 🤔

[rubensworks]

I'm pretty sure that the RDF* factory should ensure it produces compliant terms. Otherwise you might have unexpected results?

Sure, but strictly speaking it should also take in compliant terms :-)

Is there a spec for this? I tried to config what you said but all examples I found for RDF* only used quad term in subject position 🤔

Not yet AFAIK. But here's the formal definition: http://olafhartig.de/files/Hartig_AMW2017_RDFStar.pdf (section 2.1)

[tpluscode]

Sure, but strictly speaking it should also take in compliant terms :-)

Disagreed. For the sake of interoperability a factory should (must?) accept non-compliant terms. This is why rdf-ext works flawlessly with terms produced by other factories.

Hartig_AMW2017_RDFStar.pdf (section 2.1)

Thanks, that section indeed says that:

RDF⋆ extends the notion of such triples by allowing for triples that have another triple in its subject or its object position

Thus, a similar logic I implemented for subjects should be repeated for objects. This is necessary for robustness as stated by Postel's Law

[rubensworks]

Let's agree to disagree. I understand your motivation for adding this into the factory, but at the same time I need a data factory that is as lightweight as possible for performance reasons.
If this is not the goal of this package here, feel free to close my PR.

[bergos]

Thanks for the PR. Looks good to me.

I'm pretty sure that the RDF* factory should ensure it produces compliant terms. Otherwise you might have unexpected results?

The spec says We don't define any validation. One can argue if this is already a validation, but the intention was to define only the bare minimum for people that like to have maximum performance or do some kind of validation in another step. Other implementations or implementations on top of this package can still add some kind of validation.

Side-note: quad terms can also occur in the object position. (in generalized RDF even in every position)

I don't think we should focus too much on RDF*. We defined a way to use the Quad as a Term. If some library implements it with RDF* validation, that's fine. If somebody likes to use it differently for a good reason, that's also fine. That's why I also think we should not declare it experimental, just because the RDF* spec is not yet finished. If required we can discuss this more in detail in the RDF* explanation and link issue. Btw. I would be happy about any more detailed proposals for the content for that RDF* explanation for the spec.

[larsrh]

Is there a reason why this dependency is relaxed to * instead of ^4?

[tpluscode]

A ^4 range excludes future major updates when that package becomes 5.0. This can cause npm to install duplicate versions of the typings package leading to compile issues from TypeScript, especially in monorepo scenarios

[larsrh]

I'm confused: compile errors is exactly what one would want if the typings are incompatible, no?

[tpluscode]

It's false negatives I'm talking about. Not really about incompatible types. The error looks similar to

src/index.ts(3,14): error TS2742: The inferred type of 'NamedNode' cannot be named without a reference to '../packages/in-monorepo/node_modules/rdf-js'. This is likely not portable. A type annotation is necessary.

[bergos]

published as new minor version 1.2.0