public interface Converter
Converters are always invoked in the context of the generation of a node inside the nodes
clause; nonetheless, the returned value is not required to be an RDF term. In such cases when the returned
object is not suitable for the assignment to the placeholder, it is assumed that the converter is combined
with other converters, thus forming a chain of converters that ultimately produces the node value for the
placeholder.
This is a tagging interface that does not define any operation. Indeed, its purpose is to mark objects as being CODA converters. The expectations on the functionality of a converter can be documented through the definition of a subinterface that established the contract for a family of functionally equivalent converters.
A converter should be registered in the OSGi service registry under the generic interface
Converter
with the following properties:
OSGI_SERVICE_PROPERTY_CONVERTER
)#OSGI_SERVICE_PROPERTY_CONTRACT_INTERFACE
)
The URI identifying a contract should be advertised inside the corresponding interface via a string
constant named CONTRACT_URI
.
A converter should implement one or more interfaces establishing the contracts it is obliged to. Then, it
is possible to invoke the operations implemented by a converter that adhere to some conventions. The
expectations on the signature of an operation depend on whether the converter will be used to generate a
IRI
or a Literal
.
In the context of a IRI
generation, the expected signature is as follows:
Q produceURI(CODAContext ctx, T value [, S_i param_i]*) [throws ConverterException];
where T
is type of the first parameter, the value of which depends on the position of the
converter inside the chain associated with a placeholder definition in the nodes
section.
java.lang.String
. Even if a converter does not use that information, and thus can be invoked
with a null
feature path, the argument will nonetheless a null
string.
Concerning Q
, we can say that:
IRI
, if the converter is intended to be used as
last component of a chain
In addition to the parameter value
the signature may include an arbitrary number of additional
parameters. Currently, the PEARL language only supports strings, various types of ARTNodes and maps, whose
keys are Strings and values are either strings or nodes.
In the context of a Literal
generation, the expected signature is as follows:
Q produceLiteral(CODAContext ctx, String datatype, String lang, T value [, S_i param_i]*) [throws ConverterException];
where the parameter value
has exactly the same characteristics as in the case above concerning
URIs. An analogous discourse applied to the return value, which allows or not the use of the converter at
the end of a chain, depending on whether or not it is assignable to Literal. The additional parameters
lang
and datatype
hold, respectively, the language tag and the datatype type,
statically specified in a node declaration.
Modifier and Type | Field and Description |
---|---|
static String |
OSGI_SERVICE_PROPERTY_CONTRACT |
static String |
OSGI_SERVICE_PROPERTY_CONVERTER |
static String |
STATIC_FIELD_CONTRACT_URI |
static String |
STATIC_FIELD_CONVERTER_URI |
static final String STATIC_FIELD_CONTRACT_URI
static final String STATIC_FIELD_CONVERTER_URI
static final String OSGI_SERVICE_PROPERTY_CONVERTER
static final String OSGI_SERVICE_PROPERTY_CONTRACT
Copyright © 2022 ART Group, University of Rome, Tor Vergata. All rights reserved.