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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DatasetProposal.tar.gz
Type: application/x-compressed-tar
Size: 46608 bytes
Desc: not available
URL: <http://lists.opentox.org/pipermail/development/attachments/20091203/17f886dd/attachment.bin>