On Tue, 2009-12-22 at 15:21 +0200, chung wrote:
> On Mon, 2009-12-21 at 22:13 +0200, Nina Jeliazkova wrote:
> > Martin Guetlein wrote:
> > > Hello All,
> > >
> > > Tobias Girschick wrote:
> > >   
> > >> Hello Nina,
> > >>
> > >> On Mon, 2009-12-21 at 14:21 +0200, Nina Jeliazkova wrote:
> > >> [...]
> > >>
> > >>     
> > >>>> RDF representations, structurally, contain much more (meta)information
> > >>>> about the objects they describe than ARFFs, so this piece of
> > >>>> information in the text/x-arff (the datatype of each feature) IMHO has
> > >>>> to be included in the RDF or at least - in order not to modify the RDF
> > >>>> standards we adopted in API 1.1 - we should use proper XSD datatypes
> > >>>> for every value. After all, its not 1^^double, 1^^string and
> > >>>> 1^^nominal is not the same and won't (shouldn't) be handled the same
> > >>>> way by a training algorithm.
> > >>>>
> > >>>>         
> > >>> Yes, especially for nominals, it would be better to introduce subclass
> > >>> of Feature, rather than using XSD types for denoting the types.  I might
> > >>> try to extend opentox.owl next days.
> > >>>
> > >>>       
> > >> This would be great. At the moment, classification is not possible as it
> > >> relies on a nominal target feature. Will this be reflected in the
> > >> text/x-arff, too?
> > >>     
> > >
> > > Apart from feature value type I would like to have a "feature range"
> > > as well. This should be a property of a feature, which gives me all
> > > the possible feature values of a nominal feature (e.g. active,
> > > moderately-active, inactive). This is needed when validating a
> > > prediction algorithm.
> > >
> > > What do you think?
> > >   
> > 
> > Yes, we might extend  opentox.owl class with a NominalFeature , a
> > subclass of Feature and introduce a property like ot:nominalValues ,
> > which allows specifying set of String values. If a dataset includes such
> > NominalFeature , one would be able to retrieve set of values ,that are
> > allowed by inspecting values of the ot:nominalValues property. 
> > 
> > This will be more or less equivalent to Weka nominal attributes, where
> > the allowed values are listed in the ARFF file header .
> > 
> 
> Wouldn't it be better and simpler if the property ot:nominalValues has
> as domain ot:Feature instead of ot:NominalFeature. I mean, do we need to
> extend ot:Feature to ot:DoubleFeature, ot:StringFeature and
> ot:NominalFeature? I think it would be better if we intoduced the
> property ot:hasDataType and then introduce a set of datatypes based on
> the existing XSD ones. for example:
> 
> <featureUri> <ot:hasDataType> <dataTypeURI>
> or
> <dataTypeUri> <ot:isA> <ot:Nominal>
> <dataTypeUri> <ot:acceptsValue> "1"
> <dataTypeUri> <ot:acceptsValue> "1"
> <dataTypeUri> <ot:acceptsValue> "1"
> 

*** Sorry, I sent the previous message by mistake before completing  it!
so my suggestion is:
<featureUri> <ot:hasDataType> <anonymousDataTypeURI>
<anonymousDataTypeURI> <ot:isA> <ot:Nominal>
<anonymousDataTypeURI> <ot:acceptsValue> "1"^^xsd:string
<anonymousDataTypeURI> <ot:acceptsValue> "2"^^xsd:string
<anonymousDataTypeURI> <ot:acceptsValue> "3"^^xsd:string

in case of double or string features its even easier.

Best Regards,
Pantelis




> 
> > Best regards,
> > Nina
> > > Best regards,
> > > Martin
> > >
> > >
> > >   
> > 
> > _______________________________________________
> > 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
>