Generalize term, triple, and graph

While using existing most of the existing term, triple, and graph struct definitions, create a distinction between RDF- binding-, and generic data sets:

Terms

Rename UNDEFINED term type to GENERIC or RAW. This term is allowed to carry arbitrary data.
Rplace the char * datatype of LSUP_Term.data with a union of char * and void *.
Add a data_type slot to the LSUP_Term.metadata union. This field contains a numeric code with the purpose of casting the void pointer to the correct type on term read.
Rename datatype in the LSUP_Term union to lt_type to avoid confusion. (Note: this change is not backwards-compatible)
Maintain a list of numeric types (enums) representing native C types, and a function (possibly implemented as X-macro) that interprets a term content with the indicated data type code. At least the basic stlibc data types should be supported. Clients can add data of types not in the list, in which case they are responsible for keeping track of the data type stored, and casting the data to the correct type. A client-defined type code MAY be stored in the term metadata for that purpose.
Add functionality in the term module to depracate the undefined term type and correctly handle generic terms.

Triples

While keeping the current LSUP_Triple data structure unchanged, distinguish between RDF triples, generic triples, and binding triples:

RDF triples' terms must respond to specific type constraints depending on their position: S MUST be a URI or BNode, P MUST be a URI, and O MAY be any term except for generic.
Generic triples are a superset of RDF binding triples and MAY have any term type in any position. That said, it makes most sense that they only have generic terms, as RDF terms would have no special meaning here.
Binding triples are a superset of generic triples. Any and all of its terms MAY be NULL. This is the type passed to lookup-based functions, which admit unbound terms.

Implementation:

Add validation methods for RDF and generic triples.
Add creation functions for different triple types (best as macros combining a generic create/init function with validation).

Graphs

While maintaining the current LSUP_Graph data structure definition, distinguish between RDF graphs and generic graphs:

Add a validation function for RDF graphs. The validation passes if all triples pass the RDF triple validation. Otherwise, the graph is considered a generic graph and SHOULD not be passed to functions expecting an RDF graph. In order to avoid unnecessary parsing at every function call, the client is responsible for performing graph validation prior to passing to RDF-specific functions.

Stores

Add a new flag to the store structure definition to mark a store as RDF-specific. If this flag is set to false, the store is considered generic and some RDF-specific functions cannot be run; additionally, some other functions will treat all terms in it as generic. If true, incoming triples will be validated for RDF conformance before inserting.

While using existing most of the existing term, triple, and graph struct definitions, create a distinction between RDF- binding-, and generic data sets: ## Terms - Rename `UNDEFINED` term type to `GENERIC` or `RAW`. This term is allowed to carry arbitrary data. - Rplace the `char *` datatype of `LSUP_Term.data` with a union of `char *` and `void *`. - Add a `data_type` slot to the `LSUP_Term.metadata` union. This field contains a numeric code with the purpose of casting the void pointer to the correct type on term read. - Rename `datatype` in the `LSUP_Term` union to `lt_type` to avoid confusion. (Note: this change is not backwards-compatible) - Maintain a list of numeric types (enums) representing native C types, and a function (possibly implemented as X-macro) that interprets a term content with the indicated data type code. At least the basic stlibc data types should be supported. Clients can add data of types not in the list, in which case they are responsible for keeping track of the data type stored, and casting the data to the correct type. A client-defined type code MAY be stored in the term metadata for that purpose. - Add functionality in the term module to depracate the undefined term type and correctly handle generic terms. ## Triples While keeping the current `LSUP_Triple` data structure unchanged, distinguish between RDF triples, generic triples, and binding triples: - RDF triples' terms must respond to specific type constraints depending on their position: S MUST be a URI or BNode, P MUST be a URI, and O MAY be any term except for generic. - Generic triples are a superset of RDF binding triples and MAY have any term type in any position. That said, it makes most sense that they only have generic terms, as RDF terms would have no special meaning here. - Binding triples are a superset of generic triples. Any and all of its terms MAY be NULL. This is the type passed to lookup-based functions, which admit unbound terms. Implementation: - Add validation methods for RDF and generic triples. - Add creation functions for different triple types (best as macros combining a generic create/init function with validation). ## Graphs While maintaining the current `LSUP_Graph` data structure definition, distinguish between RDF graphs and generic graphs: - Add a validation function for RDF graphs. The validation passes if all triples pass the RDF triple validation. Otherwise, the graph is considered a generic graph and SHOULD not be passed to functions expecting an RDF graph. In order to avoid unnecessary parsing at every function call, the client is responsible for performing graph validation prior to passing to RDF-specific functions. ## Stores Add a new flag to the store structure definition to mark a store as RDF-specific. If this flag is set to false, the store is considered generic and some RDF-specific functions cannot be run; additionally, some other functions will treat all terms in it as generic. If true, incoming triples will be validated for RDF conformance before inserting.

#9 Generalize term, triple, and graph

Terms

Triples

Graphs

Stores