Literal, variable, resource in one object?

[Steve Vestal <st...@adventiumlabs.com>]

I'm curious if there is an elegant, Jena-style way to do the following
(which can be done pragmatically in many ways).

I'd like to have a single object that can be any of a literal, a
variable, or a resource in a specific model.

RDFNode can be either a literal or a resource in a specific model.

Node can be either a literal or a variable.  (I can find no
getVariable() method.  Does toString() return the variable String used
when created?)

Is there a simple way to have all three using an existing Jena
interface?  Something that will provide methods isLiteral(),
isVariable(), and isResource(); and getLiteral(), getVariable() (or
equivalent), and getResource();  all on the same object?

Re: Literal, variable, resource in one object?

[Andy Seaborne <an...@apache.org>]

On 09/06/2020 12:23, Steve Vestal wrote:
> I'm curious if there is an elegant, Jena-style way to do the following
> (which can be done pragmatically in many ways).
> 
> I'd like to have a single object that can be any of a literal, a
> variable, or a resource in a specific model.
> 
> RDFNode can be either a literal or a resource in a specific model.

Or a variable - there just isn't a subclass to represent it.

    Graph g = SSE.parseGraph("(graph (?x :p :o))");
    Model model = ModelFactory.createModelForGraph(g);
    model.listStatements().forEachRemaining(System.out::println);

The Model API is designed for data with typing.

> Node can be either a literal or a variable.  (I can find no
> getVariable() method.  Does toString() return the variable String used
> when created?)

Node.isVariable
Node.getName

(and SPARQL uses class Var which is a subclass of Node_Variable)

> Is there a simple way to have all three using an existing Jena
> interface?  Something that will provide methods isLiteral(),
> isVariable(), and isResource(); and getLiteral(), getVariable() (or
> equivalent), and getResource();  all on the same object?

Likely, you want to work at the Graph layer because triples are not 
asymmetric.

In SPARQL or rules, it is quite natural to end up with e.g. literals in 
the subject position. It much easier to allow it then exclude it later 
than test every time.

     Andy