Refactor bucket map

[pietercolpaert]

Instead of having a map like this: root → ["a", ... ]

Let’s design it as root→ [{ value: "a", type: "SubstringRelation", nodeId: "a", remainingItems: 5}, ...]

This way, the bucketizer can look up all parameters necessary to correctly describe the fragmentation in a generic way. It will open the door to mixed fragment trees as well.

The geospatial bucketizer then could keep a map like this: root→ [{ value: "POLYGON (... ... ...)", type: "GeospatiallyContainsRelation", nodeId: "x/y/z", remainingItems: 5}, ...]

Question: value is usually an RDF.Term when we get it from the web. Do we already of here need to describe it as an RDF.Term instead of merely a string? E.g., it could be that the value is a literal with a specific datatype (e.g., xsd:dateTIme), then that has a huge influence on a GreaterThanRelation, as the datetime will need to be compared based on later in time.

[ddvlanck]

In the TREEcg/types repository, we added this as RelationParameters in version 0.0.11.

RelationParameters is an interface with the following properties:

• nodeId → string representing the node id
• type → RelationType (which is an enum with all relation types that currently exist in the TREE spec)
• value (optional) → Array of RDF.Term
• remainingItems (optional) → number

The abstract class Bucketizer, contains hypermediacontrols as a Map<string, RelationParameters[]>.