| | 1 | {{{ |
| | 2 | #!html |
| | 3 | <div class="documentDescription">How to create Adapters for your own data sources.</div> |
| | 4 | |
| | 5 | |
| | 6 | |
| | 7 | <div class="plain"> |
| | 8 | <p>Authors: Leo Sauermann, Shen Jinping,</p> |
| | 9 | <p>In brief, you will</p> |
| | 10 | |
| | 11 | <ul> |
| | 12 | <li>Write an ontology</li> |
| | 13 | <li>Write a Mapping</li> |
| | 14 | <li>Implement the Class</li> |
| | 15 | |
| | 16 | <li>Test it</li> |
| | 17 | <li>Deploy it</li> |
| | 18 | |
| | 19 | </ul> |
| | 20 | <p>Implementing an Adapter</p> |
| | 21 | <p>Implement an adapter involves these steps</p> |
| | 22 | |
| | 23 | <ol> |
| | 24 | <li> Make a package to contain your implementation classes</li> |
| | 25 | <li> Name your ontology “ontology.rdfs” and copy to the new created package.</li> |
| | 26 | |
| | 27 | <li> Define the ontology mapping. In gnowsis the ontology elements from the RDFS ontology are mapped to Java classes (resource wrappers and property wrappers). This mapping must be explicitly defined with an RDF file mapping.rdf. Information contained in this file together with the ontology will be used as configuration information of an adapter and loaded when the adapter initializes itself.</li> |
| | 28 | <li> Create your adapter class as a subclass of class “AdapterImpl”. Define the resource wrappers and property wrappers as inner classes of your adapter class. Table 1 set out the method you must define or overload for each type of the classes.</li> |
| | 29 | <li> Test the package</li> |
| | 30 | |
| | 31 | </ol> |
| | 32 | <h2>Write an ontology</h2> |
| | 33 | <p> An ontology defines the vocabularies that represent the classes of the instances and their associated properties that are expected in a hosting application. The vocabularies can be defined using RDF Schema. For more information about RDF Schema see |
| | 34 | "http://www.w3.org/TR/rdf-primer/#rdfschema".</p> |
| | 35 | <p> Name your ontology <code>ontology.rdfs</code> and put it into your java package.</p> |
| | 36 | |
| | 37 | <p> For short: The class of an instance is modeled as an "rdfs:Class" and the its associated property is then modeled as an "rdf:Property". You can specify the "rang" and "doamin" of a property. The "rang" indicats that the values of that property are instances of a designated class, and the "doamin" indicats that the property should(can) apply to a designated class. Both "rdfs:Class" and"rdf:Property" can be a "subClass" or "subProperty" of another, which enables the modeling of inheritance hierarchy. </p> |
| | 38 | <p> In gnowsis the ontology elements from the RDFS ontology are mapped to Java classes(resource wrappers and property wrappers). This mappiing must be explicitly defined with an RDF file <code>mapping.rdf</code>. Information contained in this file together with the ontology will be used as configuration information of an adapter and loaded when the adapter initializes itself</p> |
| | 39 | <h2>Make a package</h2> |
| | 40 | <p> For a clear management of the source code you should make a new pacakage to store your adapter code,which can be named as <code>org.gnowsis.XXX.adapter</code> where the "XXX" represents the application domain of the your adapter such as "email, mp3, etc.".</p> |
| | 41 | <h2>copy the ontology</h2> |
| | 42 | |
| | 43 | <p> copy the ontology and the mapping created in step 2 into the new created adapter package. </p> |
| | 44 | <h2>code your adapter</h2> |
| | 45 | <p> now it's the time to write your adapter code. all adapters do nothing other than extracting the data from a certain application. This commonality is encapsulated in the class "AdapterImpl",which serves as a super class for all type of adapter implementaions. So firstly you define a adapter class inherited from "AdapterImpl". </p> |
| | 46 | <p> remeber the ontology you created in step 2? it defines the objects(resources) and the associated properties of a certain application. They sould be mapped to resource wrappers and property wrappers. you define now these wrapper classes according to the mapping definition. it is recommended to define the wrapper classes as inner classes of the adapter, since they will only be used within the adapter implementation. </p> |
| | 47 | <p>copy / paste existing adapter and implement these things:</p> |
| | 48 | <p><table style="width: 100%; text-align: left;" border="1" cellpadding="2" |
| | 49 | cellspacing="2"> |
| | 50 | <tbody> |
| | 51 | <tr> |
| | 52 | <td style="vertical-align: top;">Class Type<br> |
| | 53 | |
| | 54 | </td> |
| | 55 | <td style="vertical-align: top;">subclass of<br> |
| | 56 | </td> |
| | 57 | <td style="vertical-align: top;">Must be defined<br> |
| | 58 | </td> |
| | 59 | <td style="vertical-align: top;">Must be overloaded<br> |
| | 60 | </td> |
| | 61 | <td style="vertical-align: top;">Description<br> |
| | 62 | </td> |
| | 63 | </tr> |
| | 64 | <tr> |
| | 65 | <td style="vertical-align: top;">adapter class<br> |
| | 66 | |
| | 67 | (e.g “MailAdapter”)<br> |
| | 68 | </td> |
| | 69 | <td style="vertical-align: top;">AdapterImpl<br> |
| | 70 | </td> |
| | 71 | <td style="vertical-align: top;">constructor<br> |
| | 72 | </td> |
| | 73 | <td style="vertical-align: top;">getResourceWrapper<br> |
| | 74 | getGnowsisUrl<br> |
| | 75 | </td> |
| | 76 | <td style="vertical-align: top;">Get the resource wrapper from |
| | 77 | its uri<br> |
| | 78 | |
| | 79 | Get the uri from the resource<br> |
| | 80 | </td> |
| | 81 | </tr> |
| | 82 | <tr> |
| | 83 | <td style="vertical-align: top;">resource wrapper<br> |
| | 84 | (e.g “ResPart”)<br> |
| | 85 | </td> |
| | 86 | <td style="vertical-align: top;">PropertyWrapperImpl<br> |
| | 87 | </td> |
| | 88 | <td style="vertical-align: top;">constructor<br> |
| | 89 | |
| | 90 | </td> |
| | 91 | <td style="vertical-align: top;">getWrapper<br> |
| | 92 | </td> |
| | 93 | <td style="vertical-align: top;">Wrap a resource and return the |
| | 94 | wrapper<br> |
| | 95 | </td> |
| | 96 | </tr> |
| | 97 | <tr> |
| | 98 | <td style="vertical-align: top;">property wrapper<br> |
| | 99 | (e.g “PropFrom”)<br> |
| | 100 | </td> |
| | 101 | <td style="vertical-align: top;">ResourceWrapperImpl<br> |
| | 102 | |
| | 103 | </td> |
| | 104 | <td style="vertical-align: top;">constructor<br> |
| | 105 | </td> |
| | 106 | <td style="vertical-align: top;">addObject<br> |
| | 107 | addSubject<br> |
| | 108 | </td> |
| | 109 | <td style="vertical-align: top;">Add the property extracted from |
| | 110 | the resource as an RDF object<br> |
| | 111 | Add the property extracted from the resource as an RDF subject<br> |
| | 112 | </td> |
| | 113 | </tr> |
| | 114 | </tbody> |
| | 115 | </table></p> |
| | 116 | |
| | 117 | <p>At the run time the gnowsis framework will firstly check the ontology and its mapping, locate the corresponding resource wrappers and property wrappers, call the overloaded methods to extract the meta-information from the resource for each property and finally build a jena graph. For more implementation detail refer to the source code.</p> |
| | 118 | <h2>Performance Optimizing </h2> |
| | 119 | <p> Last section we demonstrated how to implement a standard adapter. This approach works properly for most local resource adapter (e.g. file adapter, outlook adapter). Whereas to an adapter that has many resource/property wrappers and accesses the network to extract meta-information, the standard approach is quite inefficient. Because it always switches from a property to another, for each property it must re-access the network. The performance is therefore unacceptable. We keep the standard styled implementation just to demonstrate how to implement a general adapter. </p> |
| | 120 | <p>The base idea to improve the performance is that we keep the time consuming network access as few as possible. We extract the data for all properties within a single network access, and then directly create the jena graph. The new mail adapter is name “CBDMailAdapter”. The core of this adapter is the method “createCBD”. This method accepts an uri as input parameter, which uniquely represents the to be accessed resource. It access the specified resource extract all the property information, and then creates the jena graph. It is simple and quickly. The complicated ontology mapping is totally aborted.</p> |
| | 121 | <h2>Test</h2> |
| | 122 | <p> contents</p> |
| | 123 | |
| | 124 | </div> |
| | 125 | }}} |
