Pantelis,

Is it possible for you to send rdf or owl file, it is rather hard to
look at the screenshots and I can't really tell what are the differences
with my proposal.

You could also upload it as an alternative proposal on the RDF pages at
opentox.org.

Best regards,
Nina
chung wrote:
> Dear Nina, Christoph, All,
> Recently, I proposed a modification of the dataset RDF representation
> which IMO, and as you can see from the graph of the RDF, is a more
> compact and structured representation and the parsing becomes easier. I
> agree with Christoph that meta-data can be moved to another URI to make
> the representations lighter and - Indeed, as Nina mentioned - triples of
> the form (Compound, Feature, Value) cannot be represented as are in an
> RDF document because they don't comply with the general format (Subject,
> Predicate, Object) but this doesn't imply we can't have a lighter
> reepresentation. Personally, I believe that a "bad" API is better that
> no API, so we have to converge to a final version as soon as possible,
> unless an important issue exists. 
>
> As far as the algorithms and the models are concerned, I think the API
> is fine.
>
> Best Regards,
> Pantelis 
>
> On Wed, 2009-12-02 at 07:30 +0200, 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
>>