Hello All,

I have posted few snippets on how to use Jena (jena.sourceforge.net) to
create objects, specified in opentox.owl
(http://opentox.org/data/documents/development/RDF%20files/OpenToxOntology/view),
and then serialize to RDF.

http://opentox.org/data/documents/development/RDF%20files/JavaOnly/JenaExamples/

Hope this will be useful,
Nina

Nina Jeliazkova wrote:
> Hello Pantelis, All,
>
> chung wrote:
>   
>> Dear Nina, All,
>>
>> On Tue, 2009-12-01 at 19:21 +0200, Nina Jeliazkova wrote:
>>   
>>     
>>> chung wrote:
>>>     
>>>       
>>>> Dear All,
>>>>  According to the current API, the objects of all
>>>> "values" ( http://opentox.org/api/1.1/#values ) are Resources that have
>>>> a "value" ( http://opentox.org/api/1.1/#value ) and a
>>>> "feature" ( http://opentox.org/api/1.1/#feature ) which is a Literal.
>>>> Wouldn't it be more convenient to consider of features as Resources.
>>>> This way we establish the counterparts of the "feature definitions" of
>>>> API 1.0. 
>>>>   
>>>>       
>>>>         
>>> In the opentox.owl Feature is a Class, i.e. a Resource.   I support
>>> bringing back to API 1.1 the Feature object , in place of API 1.0
>>> feature_definition. 
>>>
>>> http://opentox.org/api/1.1/#feature  is a Property, in fact it should be better named "hasFeature".
>>>     
>>>       
>> No its not about its name. All in all, its not made to be human readable
>> so it doesn't really matter. The issue is that we use Literals to
>> describe the Features in a dataset and not Resources. A Literal cannot
>> have an RDF description, while a Resource can! [Think of Literals as
>> termination points of the RDF...]
>>     
>
> If you look closely into opentox.owl 
> http://opentox.org/data/documents/development/RDF%20files/OpenToxOntology/view
> , you will notice Feature is a Resource (owl:Classs to be exact). 
> Feature is a subclass of OpenToxResource. Below is an excerpt of
> opentox.owl :
>
>       <owl:Class rdf:about="#Feature">
>         <owl:disjointWith rdf:resource="#Compound"/>
>         <owl:disjointWith>
>           <owl:Class rdf:about="#Model"/>
>         </owl:disjointWith>
>         <owl:versionInfo rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>         >1.1</owl:versionInfo>
>         <dc:source rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>         ></dc:source>
>         <owl:disjointWith rdf:resource="#FeatureValue"/>
>         <rdfs:subClassOf rdf:resource="#OpentoxResource"/>
>         <owl:disjointWith>
>           <owl:Class rdf:about="#DataEntry"/>
>         </owl:disjointWith>
>         <dc:identifier rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>         >/feature/{featureid}</dc:identifier>
>         <dc:title rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>         ></dc:title>
>         <owl:disjointWith>
>           <owl:Class rdf:about="#Parameter"/>
>         </owl:disjointWith>
>         <owl:disjointWith>
>           <owl:Class rdf:about="#Algorithm"/>
>         </owl:disjointWith>
>         <owl:disjointWith rdf:resource="#Dataset"/>
>         <dc:description rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>         ></dc:description>
>       </owl:Class>
>
> There is a screenshot of Feature class in Protege, where it is clear it
> is not Literal :
> http://opentox.org/data/documents/development/RDF%20files/Screenshots/Feature/image_view_fullscreen
>
> And the overview of relationships between opentox objects clearly shows
> Feature is a resource ,with lot of relationships to other objects:
> http://opentox.org/data/documents/development/RDF%20files/Screenshots/Overview/image_view_fullscreen
>
>  This is different from ot:feature (lowercase letters), which is a
> property (owl:Property), relating FeatureValue (another resource!) to
> Feature.
>
>   <owl:ObjectProperty rdf:ID="feature">
>     <rdfs:range rdf:resource="#Feature"/>
>     <rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>     >FeatureValue contains a value for specific Feature, specified by this relationship.</rdfs:comment>
>     <rdfs:domain rdf:resource="#FeatureValue"/>
>     <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/>
>     <rdfs:isDefinedBy rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>     >http://opentox.org/api/1.1</rdfs:isDefinedBy>
>
>   </owl:ObjectProperty>
>
> Do please look in opentox.owl, this is where the definition of objects
> is done.  RDF allows huge variety of syntax, but the objects themselves
> and their relationships are clearly defined.
>
>   
>> For example consider of the following triple:
>>
>> S: <SomeValue> 
>> P: <http://opentox.org/api/1.1/#feature> 
>> O: "FeatureName"^^xsd:string
>>
>>   
>>     
> This triple is not correct, according to opentox.owl , because 
>
> <http://opentox.org/api/1.1/#feature> has <rdfs:range rdf:resource="#Feature"/> and  <rdfs:domain rdf:resource="#FeatureValue"/>.  This means S: can only be FeatureValue and O: can only be Feature.
>  
>
>  
>
>   
>> I just say to change this into the following triple:
>>
>> S: <SomeValue> 
>> P: <http://opentox.org/api/1.1/#feature>
>> O: <http://someOntologyForFeatures.com/feature/myFavoriteFeature> 
>>
>> What do you say? 
>>   
>>     
> Please have a look at the examples I've prepared for Feature and other
> objects at
>
> http://opentox.org/data/documents/development/RDF%20files/Feature
>
> It is explained how one can relate values with Features and  Features to
> other ontologies.
>
> A real case example (from current ambit implementation) is below: 
>
> @prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
> @prefix dc:      <http://purl.org/dc/elements/1.1/> .
> @prefix ot:      <http://www.opentox.org/api/1.1#> .
> @prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
> @prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix owl:     <http://www.w3.org/2002/07/owl#> .
>
> <http://localhost:8080/ambit2-www/feature/1>
>       a       ot:Feature .
>
> ot:FeatureValue
>       a       owl:Class .
>
> ot:Dataset
>       a       owl:Class .
>
> <http://localhost:8080/ambit2-www>
>       ot:dataEntry
>               [ a       ot:DataEntry ;
>                 ot:compound <http://localhost:8080/ambit2-www/compound/1> ;
>                 ot:values
>                         [ a       ot:FeatureValue ;
>                           ot:feature
> <http://localhost:8080/ambit2-www/feature_definition/1> ;
>                           ot:value "CH2O"
>                         ]
>               ] .
>
> ot:Compound
>       a       owl:Class .
>
> <http://localhost:8080/ambit2-www/compound/1>
>       a       ot:Compound .
>
> ot:Feature
>       a       owl:Class .
>
> ot:DataEntry
>       a       owl:Class .
>
>   
>> ** I attach an image of the graph of a dataset which complies with the
>> specifications of the current API. 
>>
>>   
>>     
> A full graph of opentox objects was published last week at
> http://opentox.org/data/documents/development/RDF%20files/Screenshots/Overview/view
> <http://opentox.org/data/documents/development/RDF%20files/Screenshots/Overview/view>
>
> Best regards,
> Nina
>
>   
>>> Best regards,
>>> Nina
>>>     
>>>       
>>>>   What is more, we're working on an RDF parser for RDF representations
>>>> of datasets using Jena (a Java Library for editing and Parsing RDFs).
>>>> Should we consider the current specifications as final or we're
>>>> expecting for other changes? Regardless of the abstraction level of our
>>>> source code, its important to know what input we should expect (in terms
>>>> of Dataset RDF representations).
>>>>       
>>>>         
>> Well, that was my main question... Should we consider of the current API
>> as final or not? Of course I don't ask for any changes in the interface.
>> I simply want to make some points more clear to avoid changes in the
>> specifications.
>>
>> Best Regards,
>> Pantelis
>>
>>   
>>     
>>>> Best Regards,
>>>> Pantelis
>>>>
>>>> _______________________________________________
>>>> Development mailing list
>>>> Development at opentox.org
>>>> http://www.opentox.org/mailman/listinfo/development
>>>>   
>>>>       
>>>>         
>>> _______________________________________________
>>> Development mailing list
>>> Development at opentox.org
>>> http://www.opentox.org/mailman/listinfo/development
>>>
>>>     
>>>       
>> _______________________________________________
>> Development mailing list
>> Development at opentox.org
>> http://www.opentox.org/mailman/listinfo/development
>>   
>>     
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>