undefined behaviour using the materialize with extra triples which are not version objects

[woutslabbinck]

Problem

How should materialize behave when the member has a link to other triples that are contained in the RDF.Quad[] input?
For example how should <http://example.org/> <http://purl.org/dc/terms/title> "test" . be handled when using the following input:

<http://example.org/ex#v1> <http://purl.org/dc/terms/title> "test" .
<http://example.org/ex#v1> <http://purl.org/dc/terms/isVersionOf> <http://example.org/ex> .
<http://example.org/ex#v1> <http://purl.org/dc/terms/issued> "2021-12-15T10:00:00.000Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
<http://example.org/ex#v1> <http://extra/> <http://example.org/> .
<http://example.org/> <http://purl.org/dc/terms/title> "test" .

At the moment, while not really crashing, the materialized quad for that triple would look in the code like this: quad(undefined, namedNode("http://purl.org/dc/terms/title"), literal("\"test\""), graph("http://example.org/")).

This is due to

version-materialize-rdf.js/lib/materialize.ts

Line 61 in 2a28d04

objectIdMap.get(quad.subject.value)!,

. This call would result into undefined since "http://example.org/" is not a version object.

Proposed solution

My proposal would be to copy the triple <http://example.org/> <http://purl.org/dc/terms/title> "test" . entirely and add to the output in the materialized quads.

An example where this behaviour would be desired is the following: saving SSN or SOSA observations as a member of an LDES.

When there are complex results, like the iPhone Barometer

<Observation/346345> rdf:type sosa:Observation ;
  sosa:observedProperty <sensor/35-207306-844818-0/BMP282/atmosphericPressure> ;
  sosa:hasFeatureOfInterest  <earthAtmosphere> ;
  sosa:madeBySensor <sensor/35-207306-844818-0/BMP282> ;
  sosa:hasResult [
    rdf:type qudt-1-1:QuantityValue ;
    qudt-1-1:numericValue "101936"^^xsd:double ;
    qudt-1-1:unit qudt-unit-1-1:Pascal ] ;
  sosa:resultTime [
    rdf:type time:Instant ;
    time:inXSDDateTimeStamp "2017-06-06T12:36:13+00:00"^^xsd:dateTimeStamp ] .

The blank nodes would then also be added to the materialization.

If this proposed solution is okay for you @pietercolpaert and @ddvlanck, then I will gladly make a PR request to implement this new behaviour.