|Re: [higgins-dev] JENA proposal(s) for IdAS attribute value Java Interfaces|
In terms of copying what JENA does, I'm not fully sure how they map from a typed literal in RDF to a Java class.|
>>> "Tom Doman" <TDoman@xxxxxxxxxx> 8/31/06 4:52 PM >>>
Are you saying you're not sure how JENA deals with typed literals or how
we would define our own? Or both?
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 8/31/2006 4:35 PM >>>
I played around with JENA a little bit, and it looks like we could use
some of the interfaces to represent attribute values in IdAS.
The two interfaces that match are Literal
These both implement the RDFNode interface
So, one proposal would be to return an RDFNode from IdAS's
IAttribute.getValue(). Moreover, we'd say the RDFNode will (by
convention) always be either a Resource or Literal.
There are some oddities with this proposal:
- Not hooked into a model: In JENA, RDFNodes are part of statements
which are part of an RDF model. Consumers of IdAS might try to use the
Resource or Literal to discover where it lies in a larger statement or
in the model. CP's would likely throw some kind of "notImplemented"
exception for calls like RDFNode.inModel().
- Unsupported update methods: Resource defines a number of update,
transaction methods. These would not be implemented in the case where
we're returning a Resource as an attribute value.
So, we could use these interfaces, but because they integrate with
other parts of JENA, and offer update operations, we would only
a subset of the methods on them.
Another proposal would be to copy what we like about these interfaces
and build our own. This might not be too hard. I'm not exactly sure
typed literals are resolved to other Java classes, but other than
it seems like defining our own interfaces would be fairly
p.s. For reference, I'm attaching the Java code I used to play with
Literal and Resource.
higgins-dev mailing list