I suppose one answer is that you can get a Node from FrontsNode::asNode 
(Resource < RDFNode < FrontsNode) and a Graph from RDFNode.getModel()::getGraph 
(Model < ModelGraphInterface). I'm not entirely sure what to do to build a 
EnhGraph. And that's as much as I know about this stuff.

The only mention of the ideas in that document in our site I recall is in:

https://lists.apache.org/thread.html/ee76112a3c2de79e092100c4a66897f290410d02df080cca92f324ab@%3Cusers.jena.apache.org%3E
 
<https://lists.apache.org/thread.html/ee76112a3c2de79e092100c4a66897f290410d02df080cca92f324ab@%3Cusers.jena.apache.org%3E>

where Chris Dollin gives a bit of history. Perhaps some of the committers with 
more experience could describe it better? Do we have good examples of that 
machinery in use?

ajs6f

> On Apr 3, 2019, at 3:32 AM, Thomas Francart <[email protected]> wrote:
> 
> Hello
> 
> Le mar. 2 avr. 2019 à 21:54, ajs6f <[email protected]> a écrit :
> 
>> Personality and related types are described briefly here:
>> 
>> 
>> https://jena.apache.org/documentation/notes/jena-internals.html#enhanced-nodes
> 
> 
> Thanks, this describes what I would like to do :
> 
> ```
> 
>   1. define an interface I for the new enhanced node. (You could use just
>   the implementation class, but we've stuck with the interface, because there
>   might be different implementations)
>   2. define the implementation class C. This is just a front for the
>   enhanced node. All the state of C is reflected in the graph (except for
>   caching; but beware that the graph can change without notice).
>   3. define an Implementation class for the factory. This class defines
>   methods canWrap and wrap, which test a node to see if it is allowed to
>   represent I and construct an implementation of Crespectively.
>   4. Arrange that the personality of the graph maps the class of I to the
>   factory. At the moment we do this by using (a copy of) the built-in graph
>   personality as the personality for the enhanced graph.
> 
> ```
> 
>> 
>> 
>> I know little about them, but to my understanding, that is not a
>> well-developed part of Jena and the technical ideas there are not under
>> active development. You are noticing that when you find the constructor odd
>> and hard to fill; that's in part because it mixes Jena's API (Resource,
>> Statement, Model, etc.) with its SPI (Node, Triple, Graph, etc.).
>> 
>> Could you tell us a little more about what you are doing? Why do you want
>> to extend Resource?
>> 
> 
> I'd like to do :
> 
> 1. Define an interface that extends Resource :
> 
> ```
> public interface FoafPerson extends Resource {
>   public String getName();
> }
> ```
> 
> 2. Define an implementation :
> 
> ```
> public interface FoafPersonImpl implements FoafPerson extends ResourceImpl {
>   // constructor : how will this be called ???
>   public FoafPersonImpl(Node node, EnhGraph graph) {
>        super(node, graph);
>    }
> 
>   @Override
>   public String getName() {
>     return this.getProperty(FOAF.name).getString();
>   }
> }
> ```
> 
> 3. Define an Implementation class :
> 
> ... here, I am lost
> 
> 4. Maps the class I to the factory :
> 
> ... here, I am lost
> 
> 5. Use this; I'd like to be able to do :
> 
> ```
> Model m = ...;
> Resource r = ...;
> // obtain a view on the Resource as a Foaf Person :
> FoafPerson person = r.as(FoafPerson.class);
> System.out.println(person.getName());
> ```
> 
> Any help in filling the blanks above would be appreciated !
> 
> Thanks
> Thomas
> 
> 
>> ajs6f
>> 
>>> On Apr 2, 2019, at 3:48 PM, Thomas Francart <[email protected]>
>> wrote:
>>> 
>>> Hello
>>> 
>>> I would like to declare data structure with an Interface that extends
>> Jena
>>> Resource and its implementation that extends Jena ResourceImpl in the
>> same
>>> way as
>>> 
>> https://github.com/TopQuadrant/shacl/blob/a3f54abeffc691ff0b15bee7f049741eb6e00878/src/main/java/org/topbraid/shacl/model/SHShape.java
>>> (interface) and
>>> 
>> https://github.com/TopQuadrant/shacl/blob/a3f54abeffc691ff0b15bee7f049741eb6e00878/src/main/java/org/topbraid/shacl/model/impl/SHShapeImpl.java
>>> (implementation, which indirectly extends ResourceImpl).
>>> Is it a common and good practice ?
>>> 
>>> The constructor of the implementation takes as an input (Node node,
>>> EnhGraph graph).
>>> I don't know how to obtain or build these Node and EnhGraph from plain
>>> Resource / Model I am used to. I will be working with memory or
>> TDB-backed
>>> Models, if that matters. How can I obtain or build these so that I can
>> call
>>> the constructor of my data structure extending ResourceImpl, with a Node
>>> and EnhGraph instance ?
>>> 
>>> I feel this could be related to "Personality<RDFNode>", as can be seen at
>>> 
>> https://github.com/TopQuadrant/shacl/blob/76257beb501381542361b52363329999363753ff/src/main/java/org/topbraid/shacl/model/SHFactory.java
>> ,
>>> where RDF classes URI are associated to the corresponding Java classes.
>>> 
>>> I am lost here, could someone shed some light on this design pattern ?
>>> 
>>> Thanks
>>> Thomas
>>> 
>>> --
>>> 
>>> *Thomas Francart* -* SPARNA*
>>> Web de *données* | Architecture de l'*information* | Accès aux
>>> *connaissances*
>>> blog : blog.sparna.fr, site : sparna.fr, linkedin :
>>> fr.linkedin.com/in/thomasfrancart
>>> tel :  +33 (0)6.71.11.25.97, skype : francartthomas
>> 
>> 
> 
> -- 
> 
> *Thomas Francart* -* SPARNA*
> Web de *données* | Architecture de l'*information* | Accès aux
> *connaissances*
> blog : blog.sparna.fr, site : sparna.fr, linkedin :
> fr.linkedin.com/in/thomasfrancart
> tel :  +33 (0)6.71.11.25.97, skype : francartthomas

Reply via email to