Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

Naama Menda
On Thu, May 5, 2011 at 2:10 PM, Yuri Bendana <[hidden email]> wrote:
On Wed, May 4, 2011 at 11:02 AM, Yuri Bendana <[hidden email]> wrote:
On Wed, May 4, 2011 at 4:06 AM, seth redmond <[hidden email]> wrote:

What I do not agree with is extending these to every prop table across chado. Phenotypes are by their nature a special case; the only table I know of where we are *obliged* to use a two-part definition (e.g. ANATOMY_ONTOLOGY:'wing' + PATO:'increased size', etc). The logic of including cvalue in phenotypeprop was to allow people to use the same E-Q descriptors to describe other aspects of the same phenotype. 
In most (all?) other cases where we use a CV term in a prop table, what we are describing should be defined by the CVterm itself. To use an example we have just been discussing at VB we have CVterms for strains of mosquito - we do not need to define this as 'strain' + 'a.gambiae M' because the fact that 'a.gambiae M' is a strain is implicit in the CVterm. If this is not possible we look to modify the ontology and not the database. I am still to hear a convincing reason why this is not possible with other prop tables.

I think it's reasonable for the value of a property to be drawn from a cvterm.  It doesn't have to be just a special case for phenotypes.  For example if I had an experimental property of type_id='bucket color', I could set
 cvalue_id= 'red'. That way I'm not forced to include 'red bucket', etc in my ontology for every possible color and it's better than using the free text value field. 


 Now that I think about it, what you're saying is that properties should be precomposed in the ontology while I'm saying that adding cvalue_id allows you to postcompose properties.  At the cost of an extra column, for me this added flexibility is worth it.


The question here is whether this should be a prop in the first place. In case your value is a cvterm , you should probably store it in a *_cvterm table with

type_id = 'bucket color'
cvterm_id = 'red'

that's exactly the place for postcomposed terms
especially since the way you offer to use a prop table with a cvalue_id is to use either value or cvalue_id, but never both simultaneously .
In most prop tables the prop.value can be anything you want and not tied to a cvterm. However, I can see (and have experienced) how this usage causes problems, but I'm still not convinced extending the prop table is the right way to handle this.

-Naama

 
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver



------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

Yuri Bendana-3


On Thu, May 5, 2011 at 11:38 AM, Naama Menda <[hidden email]> wrote:
On Thu, May 5, 2011 at 2:10 PM, Yuri Bendana <[hidden email]> wrote:
On Wed, May 4, 2011 at 11:02 AM, Yuri Bendana <[hidden email]> wrote:
On Wed, May 4, 2011 at 4:06 AM, seth redmond <[hidden email]> wrote:

What I do not agree with is extending these to every prop table across chado. Phenotypes are by their nature a special case; the only table I know of where we are *obliged* to use a two-part definition (e.g. ANATOMY_ONTOLOGY:'wing' + PATO:'increased size', etc). The logic of including cvalue in phenotypeprop was to allow people to use the same E-Q descriptors to describe other aspects of the same phenotype. 
In most (all?) other cases where we use a CV term in a prop table, what we are describing should be defined by the CVterm itself. To use an example we have just been discussing at VB we have CVterms for strains of mosquito - we do not need to define this as 'strain' + 'a.gambiae M' because the fact that 'a.gambiae M' is a strain is implicit in the CVterm. If this is not possible we look to modify the ontology and not the database. I am still to hear a convincing reason why this is not possible with other prop tables.

I think it's reasonable for the value of a property to be drawn from a cvterm.  It doesn't have to be just a special case for phenotypes.  For example if I had an experimental property of type_id='bucket color', I could set
 cvalue_id= 'red'. That way I'm not forced to include 'red bucket', etc in my ontology for every possible color and it's better than using the free text value field. 


 Now that I think about it, what you're saying is that properties should be precomposed in the ontology while I'm saying that adding cvalue_id allows you to postcompose properties.  At the cost of an extra column, for me this added flexibility is worth it.


The question here is whether this should be a prop in the first place. In case your value is a cvterm , you should probably store it in a *_cvterm table with

type_id = 'bucket color'
cvterm_id = 'red'

that's exactly the place for postcomposed terms
especially since the way you offer to use a prop table with a cvalue_id is to use either value or cvalue_id, but never both simultaneously .
In most prop tables the prop.value can be anything you want and not tied to a cvterm. However, I can see (and have experienced) how this usage causes problems, but I'm still not convinced extending the prop table is the right way to handle this.

-Naama

There are a couple of issues with using *cvterm.  The first is that there are 4 times as many *prop tables as *cvterm tables (currently 42 vs 9).  The second is that there is no type_id in the *cvterm tables.
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

Yuri Bendana-3
On Thu, May 5, 2011 at 12:05 PM, Yuri Bendana <[hidden email]> wrote:


On Thu, May 5, 2011 at 11:38 AM, Naama Menda <[hidden email]> wrote:
On Thu, May 5, 2011 at 2:10 PM, Yuri Bendana <[hidden email]> wrote:
On Wed, May 4, 2011 at 11:02 AM, Yuri Bendana <[hidden email]> wrote:
On Wed, May 4, 2011 at 4:06 AM, seth redmond <[hidden email]> wrote:

What I do not agree with is extending these to every prop table across chado. Phenotypes are by their nature a special case; the only table I know of where we are *obliged* to use a two-part definition (e.g. ANATOMY_ONTOLOGY:'wing' + PATO:'increased size', etc). The logic of including cvalue in phenotypeprop was to allow people to use the same E-Q descriptors to describe other aspects of the same phenotype. 
In most (all?) other cases where we use a CV term in a prop table, what we are describing should be defined by the CVterm itself. To use an example we have just been discussing at VB we have CVterms for strains of mosquito - we do not need to define this as 'strain' + 'a.gambiae M' because the fact that 'a.gambiae M' is a strain is implicit in the CVterm. If this is not possible we look to modify the ontology and not the database. I am still to hear a convincing reason why this is not possible with other prop tables.

I think it's reasonable for the value of a property to be drawn from a cvterm.  It doesn't have to be just a special case for phenotypes.  For example if I had an experimental property of type_id='bucket color', I could set
 cvalue_id= 'red'. That way I'm not forced to include 'red bucket', etc in my ontology for every possible color and it's better than using the free text value field. 


 Now that I think about it, what you're saying is that properties should be precomposed in the ontology while I'm saying that adding cvalue_id allows you to postcompose properties.  At the cost of an extra column, for me this added flexibility is worth it.


The question here is whether this should be a prop in the first place. In case your value is a cvterm , you should probably store it in a *_cvterm table with

type_id = 'bucket color'
cvterm_id = 'red'

that's exactly the place for postcomposed terms
especially since the way you offer to use a prop table with a cvalue_id is to use either value or cvalue_id, but never both simultaneously .
In most prop tables the prop.value can be anything you want and not tied to a cvterm. However, I can see (and have experienced) how this usage causes problems, but I'm still not convinced extending the prop table is the right way to handle this.

-Naama

There are a couple of issues with using *cvterm.  The first is that there are 4 times as many *prop tables as *cvterm tables (currently 42 vs 9).  The second is that there is no type_id in the *cvterm tables.

And actually, one can use both value and cvalue_id simultaneously.  For example, if I wanted to set value=100 and cvalue_id='mm'.  You can think of this as kind of a postcomposition as well.

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

seth redmond
In reply to this post by Naama Menda
this appears to have gone quiet over the past week - do we still want to schedule a call to put some of the issues out of their misery and sort out any remaining issues with the paper? 

-s


-- 
Seth Redmond
  Scientific Programmer, VectorBase
  Kafatos / Christophides Groups
  Div. Cell and Molecular Biology
  Imperial College, London
[hidden email]
--

On 5 May 2011, at 19:38, Naama Menda wrote:

On Thu, May 5, 2011 at 2:10 PM, Yuri Bendana <[hidden email]> wrote:
On Wed, May 4, 2011 at 11:02 AM, Yuri Bendana <[hidden email]> wrote:
On Wed, May 4, 2011 at 4:06 AM, seth redmond <[hidden email]> wrote:

What I do not agree with is extending these to every prop table across chado. Phenotypes are by their nature a special case; the only table I know of where we are *obliged* to use a two-part definition (e.g. ANATOMY_ONTOLOGY:'wing' + PATO:'increased size', etc). The logic of including cvalue in phenotypeprop was to allow people to use the same E-Q descriptors to describe other aspects of the same phenotype. 
In most (all?) other cases where we use a CV term in a prop table, what we are describing should be defined by the CVterm itself. To use an example we have just been discussing at VB we have CVterms for strains of mosquito - we do not need to define this as 'strain' + 'a.gambiae M' because the fact that 'a.gambiae M' is a strain is implicit in the CVterm. If this is not possible we look to modify the ontology and not the database. I am still to hear a convincing reason why this is not possible with other prop tables.

I think it's reasonable for the value of a property to be drawn from a cvterm.  It doesn't have to be just a special case for phenotypes.  For example if I had an experimental property of type_id='bucket color', I could set
 cvalue_id= 'red'. That way I'm not forced to include 'red bucket', etc in my ontology for every possible color and it's better than using the free text value field. 


 Now that I think about it, what you're saying is that properties should be precomposed in the ontology while I'm saying that adding cvalue_id allows you to postcompose properties.  At the cost of an extra column, for me this added flexibility is worth it.


The question here is whether this should be a prop in the first place. In case your value is a cvterm , you should probably store it in a *_cvterm table with

type_id = 'bucket color'
cvterm_id = 'red'

that's exactly the place for postcomposed terms
especially since the way you offer to use a prop table with a cvalue_id is to use either value or cvalue_id, but never both simultaneously .
In most prop tables the prop.value can be anything you want and not tied to a cvterm. However, I can see (and have experienced) how this usage causes problems, but I'm still not convinced extending the prop table is the right way to handle this.

-Naama

 
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver




------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

Yuri Bendana-3
Sure, let's 'put them out of their misery'.

On Thu, May 12, 2011 at 3:47 PM, seth redmond <[hidden email]> wrote:
this appears to have gone quiet over the past week - do we still want to schedule a call to put some of the issues out of their misery and sort out any remaining issues with the paper? 

-s


-- 
Seth Redmond
  Scientific Programmer, VectorBase
  Kafatos / Christophides Groups
  Div. Cell and Molecular Biology
  Imperial College, London
--

On 5 May 2011, at 19:38, Naama Menda wrote:

On Thu, May 5, 2011 at 2:10 PM, Yuri Bendana <[hidden email]> wrote:
On Wed, May 4, 2011 at 11:02 AM, Yuri Bendana <[hidden email]> wrote:
On Wed, May 4, 2011 at 4:06 AM, seth redmond <[hidden email]> wrote:

What I do not agree with is extending these to every prop table across chado. Phenotypes are by their nature a special case; the only table I know of where we are *obliged* to use a two-part definition (e.g. ANATOMY_ONTOLOGY:'wing' + PATO:'increased size', etc). The logic of including cvalue in phenotypeprop was to allow people to use the same E-Q descriptors to describe other aspects of the same phenotype. 
In most (all?) other cases where we use a CV term in a prop table, what we are describing should be defined by the CVterm itself. To use an example we have just been discussing at VB we have CVterms for strains of mosquito - we do not need to define this as 'strain' + 'a.gambiae M' because the fact that 'a.gambiae M' is a strain is implicit in the CVterm. If this is not possible we look to modify the ontology and not the database. I am still to hear a convincing reason why this is not possible with other prop tables.

I think it's reasonable for the value of a property to be drawn from a cvterm.  It doesn't have to be just a special case for phenotypes.  For example if I had an experimental property of type_id='bucket color', I could set
 cvalue_id= 'red'. That way I'm not forced to include 'red bucket', etc in my ontology for every possible color and it's better than using the free text value field. 


 Now that I think about it, what you're saying is that properties should be precomposed in the ontology while I'm saying that adding cvalue_id allows you to postcompose properties.  At the cost of an extra column, for me this added flexibility is worth it.


The question here is whether this should be a prop in the first place. In case your value is a cvterm , you should probably store it in a *_cvterm table with

type_id = 'bucket color'
cvterm_id = 'red'

that's exactly the place for postcomposed terms
especially since the way you offer to use a prop table with a cvalue_id is to use either value or cvalue_id, but never both simultaneously .
In most prop tables the prop.value can be anything you want and not tied to a cvterm. However, I can see (and have experienced) how this usage causes problems, but I'm still not convinced extending the prop table is the right way to handle this.

-Naama

 
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver





------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

seth redmond
ok, I've put a doodle poll together which should cover all the times available between pacific and UK time over the next couple of weeks - giving us until the middle of next week to get a list of proposed changes together.
        http://www.doodle.com/ewfrpkpkacy577fs

I've also started off a wiki page for and proposed changes as I figure this will be faster than using the github issues, or similar.
        http://gmod.org/wiki/Chado_Natural_Diversity_Module/natdiv_schema_changes_call
If people could fill in their requested changes by the middle of next week it should help with drawing up the agenda. Can I also suggest that people who want changes try to keep them as succinct as possible, and include a reason for the change as well as a brief description.

-s




On 13 May 2011, at 02:23, Yuri Bendana wrote:

> Sure, let's 'put them out of their misery'.
>
> On Thu, May 12, 2011 at 3:47 PM, seth redmond <[hidden email]> wrote:
> this appears to have gone quiet over the past week - do we still want to schedule a call to put some of the issues out of their misery and sort out any remaining issues with the paper?
>
> -s
>
>
> --
> Seth Redmond
>   Scientific Programmer, VectorBase
>   Kafatos / Christophides Groups
>   Div. Cell and Molecular Biology
>   Imperial College, London
> [hidden email]
> --
>
> On 5 May 2011, at 19:38, Naama Menda wrote:
>
>> On Thu, May 5, 2011 at 2:10 PM, Yuri Bendana <[hidden email]> wrote:
>> On Wed, May 4, 2011 at 11:02 AM, Yuri Bendana <[hidden email]> wrote:
>> On Wed, May 4, 2011 at 4:06 AM, seth redmond <[hidden email]> wrote:
>>
>> What I do not agree with is extending these to every prop table across chado. Phenotypes are by their nature a special case; the only table I know of where we are *obliged* to use a two-part definition (e.g. ANATOMY_ONTOLOGY:'wing' + PATO:'increased size', etc). The logic of including cvalue in phenotypeprop was to allow people to use the same E-Q descriptors to describe other aspects of the same phenotype.
>> In most (all?) other cases where we use a CV term in a prop table, what we are describing should be defined by the CVterm itself. To use an example we have just been discussing at VB we have CVterms for strains of mosquito - we do not need to define this as 'strain' + 'a.gambiae M' because the fact that 'a.gambiae M' is a strain is implicit in the CVterm. If this is not possible we look to modify the ontology and not the database. I am still to hear a convincing reason why this is not possible with other prop tables.
>>
>> I think it's reasonable for the value of a property to be drawn from a cvterm.  It doesn't have to be just a special case for phenotypes.  For example if I had an experimental property of type_id='bucket color', I could set
>>  cvalue_id= 'red'. That way I'm not forced to include 'red bucket', etc in my ontology for every possible color and it's better than using the free text value field.
>>
>>
>>  Now that I think about it, what you're saying is that properties should be precomposed in the ontology while I'm saying that adding cvalue_id allows you to postcompose properties.  At the cost of an extra column, for me this added flexibility is worth it.
>>
>>
>> The question here is whether this should be a prop in the first place. In case your value is a cvterm , you should probably store it in a *_cvterm table with
>>
>> type_id = 'bucket color'
>> cvterm_id = 'red'
>>
>> that's exactly the place for postcomposed terms
>> especially since the way you offer to use a prop table with a cvalue_id is to use either value or cvalue_id, but never both simultaneously .
>> In most prop tables the prop.value can be anything you want and not tied to a cvterm. However, I can see (and have experienced) how this usage causes problems, but I'm still not convinced extending the prop table is the right way to handle this.
>>
>> -Naama
>>
>>  
>> ------------------------------------------------------------------------------
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network
>> management toolset available today.  Delivers lowest initial
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>> _______________________________________________
>> Gmod-phendiver mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>>
>>
>
>


------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

Scott Cain
Hi All,

I just want to reiterate and suggest that interested people fill in
the doodle poll for the call (which will take place later this week or
next).

Thanks,
Scott


On Fri, May 13, 2011 at 7:14 AM, seth redmond
<[hidden email]> wrote:

> ok, I've put a doodle poll together which should cover all the times available between pacific and UK time over the next couple of weeks - giving us until the middle of next week to get a list of proposed changes together.
>        http://www.doodle.com/ewfrpkpkacy577fs
>
> I've also started off a wiki page for and proposed changes as I figure this will be faster than using the github issues, or similar.
>        http://gmod.org/wiki/Chado_Natural_Diversity_Module/natdiv_schema_changes_call
> If people could fill in their requested changes by the middle of next week it should help with drawing up the agenda. Can I also suggest that people who want changes try to keep them as succinct as possible, and include a reason for the change as well as a brief description.
>
> -s
>
>
>
>
> On 13 May 2011, at 02:23, Yuri Bendana wrote:
>
>> Sure, let's 'put them out of their misery'.
>>
>> On Thu, May 12, 2011 at 3:47 PM, seth redmond <[hidden email]> wrote:
>> this appears to have gone quiet over the past week - do we still want to schedule a call to put some of the issues out of their misery and sort out any remaining issues with the paper?
>>
>> -s
>>
>>
>> --
>> Seth Redmond
>>   Scientific Programmer, VectorBase
>>   Kafatos / Christophides Groups
>>   Div. Cell and Molecular Biology
>>   Imperial College, London
>> [hidden email]
>> --
>>
>> On 5 May 2011, at 19:38, Naama Menda wrote:
>>
>>> On Thu, May 5, 2011 at 2:10 PM, Yuri Bendana <[hidden email]> wrote:
>>> On Wed, May 4, 2011 at 11:02 AM, Yuri Bendana <[hidden email]> wrote:
>>> On Wed, May 4, 2011 at 4:06 AM, seth redmond <[hidden email]> wrote:
>>>
>>> What I do not agree with is extending these to every prop table across chado. Phenotypes are by their nature a special case; the only table I know of where we are *obliged* to use a two-part definition (e.g. ANATOMY_ONTOLOGY:'wing' + PATO:'increased size', etc). The logic of including cvalue in phenotypeprop was to allow people to use the same E-Q descriptors to describe other aspects of the same phenotype.
>>> In most (all?) other cases where we use a CV term in a prop table, what we are describing should be defined by the CVterm itself. To use an example we have just been discussing at VB we have CVterms for strains of mosquito - we do not need to define this as 'strain' + 'a.gambiae M' because the fact that 'a.gambiae M' is a strain is implicit in the CVterm. If this is not possible we look to modify the ontology and not the database. I am still to hear a convincing reason why this is not possible with other prop tables.
>>>
>>> I think it's reasonable for the value of a property to be drawn from a cvterm.  It doesn't have to be just a special case for phenotypes.  For example if I had an experimental property of type_id='bucket color', I could set
>>>  cvalue_id= 'red'. That way I'm not forced to include 'red bucket', etc in my ontology for every possible color and it's better than using the free text value field.
>>>
>>>
>>>  Now that I think about it, what you're saying is that properties should be precomposed in the ontology while I'm saying that adding cvalue_id allows you to postcompose properties.  At the cost of an extra column, for me this added flexibility is worth it.
>>>
>>>
>>> The question here is whether this should be a prop in the first place. In case your value is a cvterm , you should probably store it in a *_cvterm table with
>>>
>>> type_id = 'bucket color'
>>> cvterm_id = 'red'
>>>
>>> that's exactly the place for postcomposed terms
>>> especially since the way you offer to use a prop table with a cvalue_id is to use either value or cvalue_id, but never both simultaneously .
>>> In most prop tables the prop.value can be anything you want and not tied to a cvterm. However, I can see (and have experienced) how this usage causes problems, but I'm still not convinced extending the prop table is the right way to handle this.
>>>
>>> -Naama
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> WhatsUp Gold - Download Free Network Management Software
>>> The most intuitive, comprehensive, and cost-effective network
>>> management toolset available today.  Delivers lowest initial
>>> acquisition cost and overall TCO of any competing solution.
>>> http://p.sf.net/sfu/whatsupgold-sd
>>> _______________________________________________
>>> Gmod-phendiver mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>>>
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Gmod-phendiver mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>



--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     216-392-3087
Ontario Institute for Cancer Research

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

Robert Buels
On 05/16/2011 10:30 AM, Scott Cain wrote:
> I just want to reiterate and suggest that interested people fill in
> the doodle poll for the call (which will take place later this week or
> next).

I filled it in.  Thanks for the reminder!

R

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

seth redmond
In reply to this post by seth redmond
So it seems I forgot to send round an email scheduling this meeting last week, sorry. But we did have a clear winner on this thursday at 6pmBST / 1pm EST / 10am PST - is everyone still available for a call?

I'll put a conference call together on webex through our vectorbase account (and send the code along when I have it).

thanks

-s

--
Seth Redmond
Scientific Programmer, VectorBase
Kafatos / Christophides Groups
Div. Cell and Molecular Biology
Imperial College, London
[hidden email]
--

On 13 May 2011, at 12:14, seth redmond wrote:

> ok, I've put a doodle poll together which should cover all the times available between pacific and UK time over the next couple of weeks - giving us until the middle of next week to get a list of proposed changes together.
> http://www.doodle.com/ewfrpkpkacy577fs
>
> I've also started off a wiki page for and proposed changes as I figure this will be faster than using the github issues, or similar.
> http://gmod.org/wiki/Chado_Natural_Diversity_Module/natdiv_schema_changes_call
> If people could fill in their requested changes by the middle of next week it should help with drawing up the agenda. Can I also suggest that people who want changes try to keep them as succinct as possible, and include a reason for the change as well as a brief description.
>
> -s
>
>
>
>
> On 13 May 2011, at 02:23, Yuri Bendana wrote:
>
>> Sure, let's 'put them out of their misery'.
>>
>> On Thu, May 12, 2011 at 3:47 PM, seth redmond <[hidden email]> wrote:
>> this appears to have gone quiet over the past week - do we still want to schedule a call to put some of the issues out of their misery and sort out any remaining issues with the paper?
>>
>> -s
>>
>>
>> --
>> Seth Redmond
>> Scientific Programmer, VectorBase
>> Kafatos / Christophides Groups
>> Div. Cell and Molecular Biology
>> Imperial College, London
>> [hidden email]
>> --
>>
>> On 5 May 2011, at 19:38, Naama Menda wrote:
>>
>>> On Thu, May 5, 2011 at 2:10 PM, Yuri Bendana <[hidden email]> wrote:
>>> On Wed, May 4, 2011 at 11:02 AM, Yuri Bendana <[hidden email]> wrote:
>>> On Wed, May 4, 2011 at 4:06 AM, seth redmond <[hidden email]> wrote:
>>>
>>> What I do not agree with is extending these to every prop table across chado. Phenotypes are by their nature a special case; the only table I know of where we are *obliged* to use a two-part definition (e.g. ANATOMY_ONTOLOGY:'wing' + PATO:'increased size', etc). The logic of including cvalue in phenotypeprop was to allow people to use the same E-Q descriptors to describe other aspects of the same phenotype.
>>> In most (all?) other cases where we use a CV term in a prop table, what we are describing should be defined by the CVterm itself. To use an example we have just been discussing at VB we have CVterms for strains of mosquito - we do not need to define this as 'strain' + 'a.gambiae M' because the fact that 'a.gambiae M' is a strain is implicit in the CVterm. If this is not possible we look to modify the ontology and not the database. I am still to hear a convincing reason why this is not possible with other prop tables.
>>>
>>> I think it's reasonable for the value of a property to be drawn from a cvterm.  It doesn't have to be just a special case for phenotypes.  For example if I had an experimental property of type_id='bucket color', I could set
>>> cvalue_id= 'red'. That way I'm not forced to include 'red bucket', etc in my ontology for every possible color and it's better than using the free text value field.
>>>
>>>
>>> Now that I think about it, what you're saying is that properties should be precomposed in the ontology while I'm saying that adding cvalue_id allows you to postcompose properties.  At the cost of an extra column, for me this added flexibility is worth it.
>>>
>>>
>>> The question here is whether this should be a prop in the first place. In case your value is a cvterm , you should probably store it in a *_cvterm table with
>>>
>>> type_id = 'bucket color'
>>> cvterm_id = 'red'
>>>
>>> that's exactly the place for postcomposed terms
>>> especially since the way you offer to use a prop table with a cvalue_id is to use either value or cvalue_id, but never both simultaneously .
>>> In most prop tables the prop.value can be anything you want and not tied to a cvterm. However, I can see (and have experienced) how this usage causes problems, but I'm still not convinced extending the prop table is the right way to handle this.
>>>
>>> -Naama
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> WhatsUp Gold - Download Free Network Management Software
>>> The most intuitive, comprehensive, and cost-effective network
>>> management toolset available today.  Delivers lowest initial
>>> acquisition cost and overall TCO of any competing solution.
>>> http://p.sf.net/sfu/whatsupgold-sd
>>> _______________________________________________
>>> Gmod-phendiver mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>>>
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Gmod-phendiver mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver


------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

Scott Cain
Thanks Seth, I was just thinking about that last night.  Thursday is good for me.

Scott

Sent from my iPad

On 2011-05-24, at 10:30 AM, seth redmond <[hidden email]> wrote:

> So it seems I forgot to send round an email scheduling this meeting last week, sorry. But we did have a clear winner on this thursday at 6pmBST / 1pm EST / 10am PST - is everyone still available for a call?
>
> I'll put a conference call together on webex through our vectorbase account (and send the code along when I have it).
>
> thanks
>
> -s
>
> --
> Seth Redmond
> Scientific Programmer, VectorBase
> Kafatos / Christophides Groups
> Div. Cell and Molecular Biology
> Imperial College, London
> [hidden email]
> --
>
> On 13 May 2011, at 12:14, seth redmond wrote:
>
>> ok, I've put a doodle poll together which should cover all the times available between pacific and UK time over the next couple of weeks - giving us until the middle of next week to get a list of proposed changes together.
>>    http://www.doodle.com/ewfrpkpkacy577fs
>>
>> I've also started off a wiki page for and proposed changes as I figure this will be faster than using the github issues, or similar.
>>    http://gmod.org/wiki/Chado_Natural_Diversity_Module/natdiv_schema_changes_call
>> If people could fill in their requested changes by the middle of next week it should help with drawing up the agenda. Can I also suggest that people who want changes try to keep them as succinct as possible, and include a reason for the change as well as a brief description.
>>
>> -s
>>
>>
>>
>>
>> On 13 May 2011, at 02:23, Yuri Bendana wrote:
>>
>>> Sure, let's 'put them out of their misery'.
>>>
>>> On Thu, May 12, 2011 at 3:47 PM, seth redmond <[hidden email]> wrote:
>>> this appears to have gone quiet over the past week - do we still want to schedule a call to put some of the issues out of their misery and sort out any remaining issues with the paper?
>>>
>>> -s
>>>
>>>
>>> --
>>> Seth Redmond
>>> Scientific Programmer, VectorBase
>>> Kafatos / Christophides Groups
>>> Div. Cell and Molecular Biology
>>> Imperial College, London
>>> [hidden email]
>>> --
>>>
>>> On 5 May 2011, at 19:38, Naama Menda wrote:
>>>
>>>> On Thu, May 5, 2011 at 2:10 PM, Yuri Bendana <[hidden email]> wrote:
>>>> On Wed, May 4, 2011 at 11:02 AM, Yuri Bendana <[hidden email]> wrote:
>>>> On Wed, May 4, 2011 at 4:06 AM, seth redmond <[hidden email]> wrote:
>>>>
>>>> What I do not agree with is extending these to every prop table across chado. Phenotypes are by their nature a special case; the only table I know of where we are *obliged* to use a two-part definition (e.g. ANATOMY_ONTOLOGY:'wing' + PATO:'increased size', etc). The logic of including cvalue in phenotypeprop was to allow people to use the same E-Q descriptors to describe other aspects of the same phenotype.
>>>> In most (all?) other cases where we use a CV term in a prop table, what we are describing should be defined by the CVterm itself. To use an example we have just been discussing at VB we have CVterms for strains of mosquito - we do not need to define this as 'strain' + 'a.gambiae M' because the fact that 'a.gambiae M' is a strain is implicit in the CVterm. If this is not possible we look to modify the ontology and not the database. I am still to hear a convincing reason why this is not possible with other prop tables.
>>>>
>>>> I think it's reasonable for the value of a property to be drawn from a cvterm.  It doesn't have to be just a special case for phenotypes.  For example if I had an experimental property of type_id='bucket color', I could set
>>>> cvalue_id= 'red'. That way I'm not forced to include 'red bucket', etc in my ontology for every possible color and it's better than using the free text value field.
>>>>
>>>>
>>>> Now that I think about it, what you're saying is that properties should be precomposed in the ontology while I'm saying that adding cvalue_id allows you to postcompose properties.  At the cost of an extra column, for me this added flexibility is worth it.
>>>>
>>>>
>>>> The question here is whether this should be a prop in the first place. In case your value is a cvterm , you should probably store it in a *_cvterm table with
>>>>
>>>> type_id = 'bucket color'
>>>> cvterm_id = 'red'
>>>>
>>>> that's exactly the place for postcomposed terms
>>>> especially since the way you offer to use a prop table with a cvalue_id is to use either value or cvalue_id, but never both simultaneously .
>>>> In most prop tables the prop.value can be anything you want and not tied to a cvterm. However, I can see (and have experienced) how this usage causes problems, but I'm still not convinced extending the prop table is the right way to handle this.
>>>>
>>>> -Naama
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> WhatsUp Gold - Download Free Network Management Software
>>>> The most intuitive, comprehensive, and cost-effective network
>>>> management toolset available today.  Delivers lowest initial
>>>> acquisition cost and overall TCO of any competing solution.
>>>> http://p.sf.net/sfu/whatsupgold-sd
>>>> _______________________________________________
>>>> Gmod-phendiver mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>>>>
>>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Achieve unprecedented app performance and reliability
>> What every C/C++ and Fortran developer should know.
>> Learn how Intel has extended the reach of its next-generation tools
>> to help boost performance applications - inlcuding clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> _______________________________________________
>> Gmod-phendiver mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Gmod-phendiver mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

Maren Friesen
+1

On Tue, May 24, 2011 at 7:47 AM, Scott Cain <[hidden email]> wrote:
Thanks Seth, I was just thinking about that last night.  Thursday is good for me.

Scott

Sent from my iPad

On 2011-05-24, at 10:30 AM, seth redmond <[hidden email]> wrote:

> So it seems I forgot to send round an email scheduling this meeting last week, sorry. But we did have a clear winner on this thursday at 6pmBST / 1pm EST / 10am PST - is everyone still available for a call?
>
> I'll put a conference call together on webex through our vectorbase account (and send the code along when I have it).
>
> thanks
>
> -s
>
> --
> Seth Redmond
> Scientific Programmer, VectorBase
> Kafatos / Christophides Groups
> Div. Cell and Molecular Biology
> Imperial College, London
> [hidden email]
> --
>
> On 13 May 2011, at 12:14, seth redmond wrote:
>
>> ok, I've put a doodle poll together which should cover all the times available between pacific and UK time over the next couple of weeks - giving us until the middle of next week to get a list of proposed changes together.
>>    http://www.doodle.com/ewfrpkpkacy577fs
>>
>> I've also started off a wiki page for and proposed changes as I figure this will be faster than using the github issues, or similar.
>>    http://gmod.org/wiki/Chado_Natural_Diversity_Module/natdiv_schema_changes_call
>> If people could fill in their requested changes by the middle of next week it should help with drawing up the agenda. Can I also suggest that people who want changes try to keep them as succinct as possible, and include a reason for the change as well as a brief description.
>>
>> -s
>>
>>
>>
>>
>> On 13 May 2011, at 02:23, Yuri Bendana wrote:
>>
>>> Sure, let's 'put them out of their misery'.
>>>
>>> On Thu, May 12, 2011 at 3:47 PM, seth redmond <[hidden email]> wrote:
>>> this appears to have gone quiet over the past week - do we still want to schedule a call to put some of the issues out of their misery and sort out any remaining issues with the paper?
>>>
>>> -s
>>>
>>>
>>> --
>>> Seth Redmond
>>> Scientific Programmer, VectorBase
>>> Kafatos / Christophides Groups
>>> Div. Cell and Molecular Biology
>>> Imperial College, London
>>> [hidden email]
>>> --
>>>
>>> On 5 May 2011, at 19:38, Naama Menda wrote:
>>>
>>>> On Thu, May 5, 2011 at 2:10 PM, Yuri Bendana <[hidden email]> wrote:
>>>> On Wed, May 4, 2011 at 11:02 AM, Yuri Bendana <[hidden email]> wrote:
>>>> On Wed, May 4, 2011 at 4:06 AM, seth redmond <[hidden email]> wrote:
>>>>
>>>> What I do not agree with is extending these to every prop table across chado. Phenotypes are by their nature a special case; the only table I know of where we are *obliged* to use a two-part definition (e.g. ANATOMY_ONTOLOGY:'wing' + PATO:'increased size', etc). The logic of including cvalue in phenotypeprop was to allow people to use the same E-Q descriptors to describe other aspects of the same phenotype.
>>>> In most (all?) other cases where we use a CV term in a prop table, what we are describing should be defined by the CVterm itself. To use an example we have just been discussing at VB we have CVterms for strains of mosquito - we do not need to define this as 'strain' + 'a.gambiae M' because the fact that 'a.gambiae M' is a strain is implicit in the CVterm. If this is not possible we look to modify the ontology and not the database. I am still to hear a convincing reason why this is not possible with other prop tables.
>>>>
>>>> I think it's reasonable for the value of a property to be drawn from a cvterm.  It doesn't have to be just a special case for phenotypes.  For example if I had an experimental property of type_id='bucket color', I could set
>>>> cvalue_id= 'red'. That way I'm not forced to include 'red bucket', etc in my ontology for every possible color and it's better than using the free text value field.
>>>>
>>>>
>>>> Now that I think about it, what you're saying is that properties should be precomposed in the ontology while I'm saying that adding cvalue_id allows you to postcompose properties.  At the cost of an extra column, for me this added flexibility is worth it.
>>>>
>>>>
>>>> The question here is whether this should be a prop in the first place. In case your value is a cvterm , you should probably store it in a *_cvterm table with
>>>>
>>>> type_id = 'bucket color'
>>>> cvterm_id = 'red'
>>>>
>>>> that's exactly the place for postcomposed terms
>>>> especially since the way you offer to use a prop table with a cvalue_id is to use either value or cvalue_id, but never both simultaneously .
>>>> In most prop tables the prop.value can be anything you want and not tied to a cvterm. However, I can see (and have experienced) how this usage causes problems, but I'm still not convinced extending the prop table is the right way to handle this.
>>>>
>>>> -Naama
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> WhatsUp Gold - Download Free Network Management Software
>>>> The most intuitive, comprehensive, and cost-effective network
>>>> management toolset available today.  Delivers lowest initial
>>>> acquisition cost and overall TCO of any competing solution.
>>>> http://p.sf.net/sfu/whatsupgold-sd
>>>> _______________________________________________
>>>> Gmod-phendiver mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>>>>
>>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Achieve unprecedented app performance and reliability
>> What every C/C++ and Fortran developer should know.
>> Learn how Intel has extended the reach of its next-generation tools
>> to help boost performance applications - inlcuding clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> _______________________________________________
>> Gmod-phendiver mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Gmod-phendiver mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver



--
Maren Friesen
Postdoctoral Research Associate
Dept of Molecular and Computational Biology
University of Southern California
1050 Child's Way RRI 201-B, Los Angeles, 90089
Phone: 213-741-2858 || Fax: 213-740-8631

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

Olen Vance Sluder Jr
In reply to this post by seth redmond
I would like to lurk on the call if it is open to anyone. This is a
Chado module that will very likely be of use in the future.
--
Olen


On Tue, May 24, 2011 at 09:30, seth redmond <[hidden email]> wrote:

> So it seems I forgot to send round an email scheduling this meeting last week, sorry. But we did have a clear winner on this thursday at 6pmBST / 1pm EST / 10am PST - is everyone still available for a call?
>
> I'll put a conference call together on webex through our vectorbase account (and send the code along when I have it).
>
> thanks
>
> -s
>
> --
> Seth Redmond
> Scientific Programmer, VectorBase
> Kafatos / Christophides Groups
> Div. Cell and Molecular Biology
> Imperial College, London
> [hidden email]
> --
>
> On 13 May 2011, at 12:14, seth redmond wrote:
>
>> ok, I've put a doodle poll together which should cover all the times available between pacific and UK time over the next couple of weeks - giving us until the middle of next week to get a list of proposed changes together.
>>       http://www.doodle.com/ewfrpkpkacy577fs
>>
>> I've also started off a wiki page for and proposed changes as I figure this will be faster than using the github issues, or similar.
>>       http://gmod.org/wiki/Chado_Natural_Diversity_Module/natdiv_schema_changes_call
>> If people could fill in their requested changes by the middle of next week it should help with drawing up the agenda. Can I also suggest that people who want changes try to keep them as succinct as possible, and include a reason for the change as well as a brief description.
>>
>> -s
>>
>>
>>
>>
>> On 13 May 2011, at 02:23, Yuri Bendana wrote:
>>
>>> Sure, let's 'put them out of their misery'.
>>>
>>> On Thu, May 12, 2011 at 3:47 PM, seth redmond <[hidden email]> wrote:
>>> this appears to have gone quiet over the past week - do we still want to schedule a call to put some of the issues out of their misery and sort out any remaining issues with the paper?
>>>
>>> -s
>>>
>>>
>>> --
>>> Seth Redmond
>>> Scientific Programmer, VectorBase
>>> Kafatos / Christophides Groups
>>> Div. Cell and Molecular Biology
>>> Imperial College, London
>>> [hidden email]
>>> --
>>>
>>> On 5 May 2011, at 19:38, Naama Menda wrote:
>>>
>>>> On Thu, May 5, 2011 at 2:10 PM, Yuri Bendana <[hidden email]> wrote:
>>>> On Wed, May 4, 2011 at 11:02 AM, Yuri Bendana <[hidden email]> wrote:
>>>> On Wed, May 4, 2011 at 4:06 AM, seth redmond <[hidden email]> wrote:
>>>>
>>>> What I do not agree with is extending these to every prop table across chado. Phenotypes are by their nature a special case; the only table I know of where we are *obliged* to use a two-part definition (e.g. ANATOMY_ONTOLOGY:'wing' + PATO:'increased size', etc). The logic of including cvalue in phenotypeprop was to allow people to use the same E-Q descriptors to describe other aspects of the same phenotype.
>>>> In most (all?) other cases where we use a CV term in a prop table, what we are describing should be defined by the CVterm itself. To use an example we have just been discussing at VB we have CVterms for strains of mosquito - we do not need to define this as 'strain' + 'a.gambiae M' because the fact that 'a.gambiae M' is a strain is implicit in the CVterm. If this is not possible we look to modify the ontology and not the database. I am still to hear a convincing reason why this is not possible with other prop tables.
>>>>
>>>> I think it's reasonable for the value of a property to be drawn from a cvterm.  It doesn't have to be just a special case for phenotypes.  For example if I had an experimental property of type_id='bucket color', I could set
>>>> cvalue_id= 'red'. That way I'm not forced to include 'red bucket', etc in my ontology for every possible color and it's better than using the free text value field.
>>>>
>>>>
>>>> Now that I think about it, what you're saying is that properties should be precomposed in the ontology while I'm saying that adding cvalue_id allows you to postcompose properties.  At the cost of an extra column, for me this added flexibility is worth it.
>>>>
>>>>
>>>> The question here is whether this should be a prop in the first place. In case your value is a cvterm , you should probably store it in a *_cvterm table with
>>>>
>>>> type_id = 'bucket color'
>>>> cvterm_id = 'red'
>>>>
>>>> that's exactly the place for postcomposed terms
>>>> especially since the way you offer to use a prop table with a cvalue_id is to use either value or cvalue_id, but never both simultaneously .
>>>> In most prop tables the prop.value can be anything you want and not tied to a cvterm. However, I can see (and have experienced) how this usage causes problems, but I'm still not convinced extending the prop table is the right way to handle this.
>>>>
>>>> -Naama
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> WhatsUp Gold - Download Free Network Management Software
>>>> The most intuitive, comprehensive, and cost-effective network
>>>> management toolset available today.  Delivers lowest initial
>>>> acquisition cost and overall TCO of any competing solution.
>>>> http://p.sf.net/sfu/whatsupgold-sd
>>>> _______________________________________________
>>>> Gmod-phendiver mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>>>>
>>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Achieve unprecedented app performance and reliability
>> What every C/C++ and Fortran developer should know.
>> Learn how Intel has extended the reach of its next-generation tools
>> to help boost performance applications - inlcuding clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> _______________________________________________
>> Gmod-phendiver mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

Hilmar Lapp-3
In reply to this post by seth redmond
Yes that works for me.

        -hilmar

On May 24, 2011, at 10:30 AM, seth redmond wrote:

> So it seems I forgot to send round an email scheduling this meeting  
> last week, sorry. But we did have a clear winner on this thursday at  
> 6pmBST / 1pm EST / 10am PST - is everyone still available for a call?
>
> I'll put a conference call together on webex through our vectorbase  
> account (and send the code along when I have it).
>
> thanks
>
> -s
>
> --
> Seth Redmond
> Scientific Programmer, VectorBase
> Kafatos / Christophides Groups
> Div. Cell and Molecular Biology
> Imperial College, London
> [hidden email]
> --
>
> On 13 May 2011, at 12:14, seth redmond wrote:
>
>> ok, I've put a doodle poll together which should cover all the  
>> times available between pacific and UK time over the next couple of  
>> weeks - giving us until the middle of next week to get a list of  
>> proposed changes together.
>> http://www.doodle.com/ewfrpkpkacy577fs
>>
>> I've also started off a wiki page for and proposed changes as I  
>> figure this will be faster than using the github issues, or similar.
>> http://gmod.org/wiki/Chado_Natural_Diversity_Module/natdiv_schema_changes_call
>> If people could fill in their requested changes by the middle of  
>> next week it should help with drawing up the agenda. Can I also  
>> suggest that people who want changes try to keep them as succinct  
>> as possible, and include a reason for the change as well as a brief  
>> description.
>>
>> -s
>>
>>
>>
>>
>> On 13 May 2011, at 02:23, Yuri Bendana wrote:
>>
>>> Sure, let's 'put them out of their misery'.
>>>
>>> On Thu, May 12, 2011 at 3:47 PM, seth redmond <[hidden email]
>>> > wrote:
>>> this appears to have gone quiet over the past week - do we still  
>>> want to schedule a call to put some of the issues out of their  
>>> misery and sort out any remaining issues with the paper?
>>>
>>> -s
>>>
>>>
>>> --
>>> Seth Redmond
>>> Scientific Programmer, VectorBase
>>> Kafatos / Christophides Groups
>>> Div. Cell and Molecular Biology
>>> Imperial College, London
>>> [hidden email]
>>> --
>>>
>>> On 5 May 2011, at 19:38, Naama Menda wrote:
>>>
>>>> On Thu, May 5, 2011 at 2:10 PM, Yuri Bendana  
>>>> <[hidden email]> wrote:
>>>> On Wed, May 4, 2011 at 11:02 AM, Yuri Bendana  
>>>> <[hidden email]> wrote:
>>>> On Wed, May 4, 2011 at 4:06 AM, seth redmond <[hidden email]
>>>> > wrote:
>>>>
>>>> What I do not agree with is extending these to every prop table  
>>>> across chado. Phenotypes are by their nature a special case; the  
>>>> only table I know of where we are *obliged* to use a two-part  
>>>> definition (e.g. ANATOMY_ONTOLOGY:'wing' + PATO:'increased size',  
>>>> etc). The logic of including cvalue in phenotypeprop was to allow  
>>>> people to use the same E-Q descriptors to describe other aspects  
>>>> of the same phenotype.
>>>> In most (all?) other cases where we use a CV term in a prop  
>>>> table, what we are describing should be defined by the CVterm  
>>>> itself. To use an example we have just been discussing at VB we  
>>>> have CVterms for strains of mosquito - we do not need to define  
>>>> this as 'strain' + 'a.gambiae M' because the fact that 'a.gambiae  
>>>> M' is a strain is implicit in the CVterm. If this is not possible  
>>>> we look to modify the ontology and not the database. I am still  
>>>> to hear a convincing reason why this is not possible with other  
>>>> prop tables.
>>>>
>>>> I think it's reasonable for the value of a property to be drawn  
>>>> from a cvterm.  It doesn't have to be just a special case for  
>>>> phenotypes.  For example if I had an experimental property of  
>>>> type_id='bucket color', I could set
>>>> cvalue_id= 'red'. That way I'm not forced to include 'red  
>>>> bucket', etc in my ontology for every possible color and it's  
>>>> better than using the free text value field.
>>>>
>>>>
>>>> Now that I think about it, what you're saying is that properties  
>>>> should be precomposed in the ontology while I'm saying that  
>>>> adding cvalue_id allows you to postcompose properties.  At the  
>>>> cost of an extra column, for me this added flexibility is worth it.
>>>>
>>>>
>>>> The question here is whether this should be a prop in the first  
>>>> place. In case your value is a cvterm , you should probably store  
>>>> it in a *_cvterm table with
>>>>
>>>> type_id = 'bucket color'
>>>> cvterm_id = 'red'
>>>>
>>>> that's exactly the place for postcomposed terms
>>>> especially since the way you offer to use a prop table with a  
>>>> cvalue_id is to use either value or cvalue_id, but never both  
>>>> simultaneously .
>>>> In most prop tables the prop.value can be anything you want and  
>>>> not tied to a cvterm. However, I can see (and have experienced)  
>>>> how this usage causes problems, but I'm still not convinced  
>>>> extending the prop table is the right way to handle this.
>>>>
>>>> -Naama
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> WhatsUp Gold - Download Free Network Management Software
>>>> The most intuitive, comprehensive, and cost-effective network
>>>> management toolset available today.  Delivers lowest initial
>>>> acquisition cost and overall TCO of any competing solution.
>>>> http://p.sf.net/sfu/whatsupgold-sd
>>>> _______________________________________________
>>>> Gmod-phendiver mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>>>>
>>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Achieve unprecedented app performance and reliability
>> What every C/C++ and Fortran developer should know.
>> Learn how Intel has extended the reach of its next-generation tools
>> to help boost performance applications - inlcuding clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> _______________________________________________
>> Gmod-phendiver mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Gmod-phendiver mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver

--
===========================================================
: Hilmar Lapp -:- Durham, NC -:- hlapp at drycafe dot net :
===========================================================





------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

Lacey-Anne Sanderson
Works for me as well.
~Lacey

------------------------------------------------------
Lacey-Anne Sanderson
Bioinformaticist
Pulse Crop Breeding and Genetics
Phone: (306) 966-2430
Room 3D10 Agriculture
Department of Plant Sciences
University of Saskatchewan

On 2011-05-24, at 12:32 PM, Hilmar Lapp wrote:

Yes that works for me.

-hilmar

On May 24, 2011, at 10:30 AM, seth redmond wrote:

So it seems I forgot to send round an email scheduling this meeting  
last week, sorry. But we did have a clear winner on this thursday at  
6pmBST / 1pm EST / 10am PST - is everyone still available for a call?

I'll put a conference call together on webex through our vectorbase  
account (and send the code along when I have it).

thanks

-s

--
Seth Redmond
Scientific Programmer, VectorBase
Kafatos / Christophides Groups
Div. Cell and Molecular Biology
Imperial College, London
[hidden email]
--

On 13 May 2011, at 12:14, seth redmond wrote:

ok, I've put a doodle poll together which should cover all the  
times available between pacific and UK time over the next couple of  
weeks - giving us until the middle of next week to get a list of  
proposed changes together.
http://www.doodle.com/ewfrpkpkacy577fs

I've also started off a wiki page for and proposed changes as I  
figure this will be faster than using the github issues, or similar.
http://gmod.org/wiki/Chado_Natural_Diversity_Module/natdiv_schema_changes_call
If people could fill in their requested changes by the middle of  
next week it should help with drawing up the agenda. Can I also  
suggest that people who want changes try to keep them as succinct  
as possible, and include a reason for the change as well as a brief  
description.

-s




On 13 May 2011, at 02:23, Yuri Bendana wrote:

Sure, let's 'put them out of their misery'.

On Thu, May 12, 2011 at 3:47 PM, seth redmond <[hidden email]
wrote:
this appears to have gone quiet over the past week - do we still  
want to schedule a call to put some of the issues out of their  
misery and sort out any remaining issues with the paper?

-s


--
Seth Redmond
Scientific Programmer, VectorBase
Kafatos / Christophides Groups
Div. Cell and Molecular Biology
Imperial College, London
[hidden email]
--

On 5 May 2011, at 19:38, Naama Menda wrote:

On Thu, May 5, 2011 at 2:10 PM, Yuri Bendana  
<[hidden email]> wrote:
On Wed, May 4, 2011 at 11:02 AM, Yuri Bendana  
<[hidden email]> wrote:
On Wed, May 4, 2011 at 4:06 AM, seth redmond <[hidden email]
wrote:

What I do not agree with is extending these to every prop table  
across chado. Phenotypes are by their nature a special case; the  
only table I know of where we are *obliged* to use a two-part  
definition (e.g. ANATOMY_ONTOLOGY:'wing' + PATO:'increased size',  
etc). The logic of including cvalue in phenotypeprop was to allow  
people to use the same E-Q descriptors to describe other aspects  
of the same phenotype.
In most (all?) other cases where we use a CV term in a prop  
table, what we are describing should be defined by the CVterm  
itself. To use an example we have just been discussing at VB we  
have CVterms for strains of mosquito - we do not need to define  
this as 'strain' + 'a.gambiae M' because the fact that 'a.gambiae  
M' is a strain is implicit in the CVterm. If this is not possible  
we look to modify the ontology and not the database. I am still  
to hear a convincing reason why this is not possible with other  
prop tables.

I think it's reasonable for the value of a property to be drawn  
from a cvterm.  It doesn't have to be just a special case for  
phenotypes.  For example if I had an experimental property of  
type_id='bucket color', I could set
cvalue_id= 'red'. That way I'm not forced to include 'red  
bucket', etc in my ontology for every possible color and it's  
better than using the free text value field.


Now that I think about it, what you're saying is that properties  
should be precomposed in the ontology while I'm saying that  
adding cvalue_id allows you to postcompose properties.  At the  
cost of an extra column, for me this added flexibility is worth it.


The question here is whether this should be a prop in the first  
place. In case your value is a cvterm , you should probably store  
it in a *_cvterm table with

type_id = 'bucket color'
cvterm_id = 'red'

that's exactly the place for postcomposed terms
especially since the way you offer to use a prop table with a  
cvalue_id is to use either value or cvalue_id, but never both  
simultaneously .
In most prop tables the prop.value can be anything you want and  
not tied to a cvterm. However, I can see (and have experienced)  
how this usage causes problems, but I'm still not convinced  
extending the prop table is the right way to handle this.

-Naama


------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver






------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver


------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver

--
===========================================================
: Hilmar Lapp -:- Durham, NC -:- hlapp at drycafe dot net :
===========================================================





------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver


------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

seth redmond
great, details for the call are below; if anyone has any other items to add to the agenda please do so here (we currently don't have anything relating to the paper itself, for instance):
        http://gmod.org/wiki/Chado_Natural_Diversity_Module/natdiv_schema_changes_call

Speak to you all on thursday

-s





Date: Thursday, May 26, 2011
Starting time:   1:00 pm, Eastern Daylight Time

Teleconference:  
Call-in toll-free number (US/Canada):                  1-866-469-3239
Call-in toll number (US/Canada):                            1-650-429-3300
Call-in toll number (US/Canada)*:                         1-408-856-9570

Greece toll free:                                                 00800-12-6759
UK toll:                                                             44 (0) 207 365 1860  
UK toll free:                                                       0800-028-8023

ATTENDEE ACCESS CODE: 21813838





On 24 May 2011, at 19:36, Lacey-Anne Sanderson wrote:

> Works for me as well.
> ~Lacey
>
> ------------------------------------------------------
> Lacey-Anne Sanderson
> Bioinformaticist
> Pulse Crop Breeding and Genetics
> Phone: (306) 966-2430
> Email: [hidden email]
> Room 3D10 Agriculture
> Department of Plant Sciences
> University of Saskatchewan
>
> On 2011-05-24, at 12:32 PM, Hilmar Lapp wrote:
>
>> Yes that works for me.
>>
>> -hilmar
>>
>> On May 24, 2011, at 10:30 AM, seth redmond wrote:
>>
>>> So it seems I forgot to send round an email scheduling this meeting  
>>> last week, sorry. But we did have a clear winner on this thursday at  
>>> 6pmBST / 1pm EST / 10am PST - is everyone still available for a call?
>>>
>>> I'll put a conference call together on webex through our vectorbase  
>>> account (and send the code along when I have it).
>>>
>>> thanks
>>>
>>> -s
>>>
>>> --
>>> Seth Redmond
>>> Scientific Programmer, VectorBase
>>> Kafatos / Christophides Groups
>>> Div. Cell and Molecular Biology
>>> Imperial College, London
>>> [hidden email]
>>> --
>>>
>>> On 13 May 2011, at 12:14, seth redmond wrote:
>>>
>>>> ok, I've put a doodle poll together which should cover all the  
>>>> times available between pacific and UK time over the next couple of  
>>>> weeks - giving us until the middle of next week to get a list of  
>>>> proposed changes together.
>>>> http://www.doodle.com/ewfrpkpkacy577fs
>>>>
>>>> I've also started off a wiki page for and proposed changes as I  
>>>> figure this will be faster than using the github issues, or similar.
>>>> http://gmod.org/wiki/Chado_Natural_Diversity_Module/natdiv_schema_changes_call
>>>> If people could fill in their requested changes by the middle of  
>>>> next week it should help with drawing up the agenda. Can I also  
>>>> suggest that people who want changes try to keep them as succinct  
>>>> as possible, and include a reason for the change as well as a brief  
>>>> description.
>>>>
>>>> -s
>>>>
>>>>
>>>>
>>>>
>>>> On 13 May 2011, at 02:23, Yuri Bendana wrote:
>>>>
>>>>> Sure, let's 'put them out of their misery'.
>>>>>
>>>>> On Thu, May 12, 2011 at 3:47 PM, seth redmond <[hidden email]
>>>>>> wrote:
>>>>> this appears to have gone quiet over the past week - do we still  
>>>>> want to schedule a call to put some of the issues out of their  
>>>>> misery and sort out any remaining issues with the paper?
>>>>>
>>>>> -s
>>>>>
>>>>>
>>>>> --
>>>>> Seth Redmond
>>>>> Scientific Programmer, VectorBase
>>>>> Kafatos / Christophides Groups
>>>>> Div. Cell and Molecular Biology
>>>>> Imperial College, London
>>>>> [hidden email]
>>>>> --
>>>>>
>>>>> On 5 May 2011, at 19:38, Naama Menda wrote:
>>>>>
>>>>>> On Thu, May 5, 2011 at 2:10 PM, Yuri Bendana  
>>>>>> <[hidden email]> wrote:
>>>>>> On Wed, May 4, 2011 at 11:02 AM, Yuri Bendana  
>>>>>> <[hidden email]> wrote:
>>>>>> On Wed, May 4, 2011 at 4:06 AM, seth redmond <[hidden email]
>>>>>>> wrote:
>>>>>>
>>>>>> What I do not agree with is extending these to every prop table  
>>>>>> across chado. Phenotypes are by their nature a special case; the  
>>>>>> only table I know of where we are *obliged* to use a two-part  
>>>>>> definition (e.g. ANATOMY_ONTOLOGY:'wing' + PATO:'increased size',  
>>>>>> etc). The logic of including cvalue in phenotypeprop was to allow  
>>>>>> people to use the same E-Q descriptors to describe other aspects  
>>>>>> of the same phenotype.
>>>>>> In most (all?) other cases where we use a CV term in a prop  
>>>>>> table, what we are describing should be defined by the CVterm  
>>>>>> itself. To use an example we have just been discussing at VB we  
>>>>>> have CVterms for strains of mosquito - we do not need to define  
>>>>>> this as 'strain' + 'a.gambiae M' because the fact that 'a.gambiae  
>>>>>> M' is a strain is implicit in the CVterm. If this is not possible  
>>>>>> we look to modify the ontology and not the database. I am still  
>>>>>> to hear a convincing reason why this is not possible with other  
>>>>>> prop tables.
>>>>>>
>>>>>> I think it's reasonable for the value of a property to be drawn  
>>>>>> from a cvterm.  It doesn't have to be just a special case for  
>>>>>> phenotypes.  For example if I had an experimental property of  
>>>>>> type_id='bucket color', I could set
>>>>>> cvalue_id= 'red'. That way I'm not forced to include 'red  
>>>>>> bucket', etc in my ontology for every possible color and it's  
>>>>>> better than using the free text value field.
>>>>>>
>>>>>>
>>>>>> Now that I think about it, what you're saying is that properties  
>>>>>> should be precomposed in the ontology while I'm saying that  
>>>>>> adding cvalue_id allows you to postcompose properties.  At the  
>>>>>> cost of an extra column, for me this added flexibility is worth it.
>>>>>>
>>>>>>
>>>>>> The question here is whether this should be a prop in the first  
>>>>>> place. In case your value is a cvterm , you should probably store  
>>>>>> it in a *_cvterm table with
>>>>>>
>>>>>> type_id = 'bucket color'
>>>>>> cvterm_id = 'red'
>>>>>>
>>>>>> that's exactly the place for postcomposed terms
>>>>>> especially since the way you offer to use a prop table with a  
>>>>>> cvalue_id is to use either value or cvalue_id, but never both  
>>>>>> simultaneously .
>>>>>> In most prop tables the prop.value can be anything you want and  
>>>>>> not tied to a cvterm. However, I can see (and have experienced)  
>>>>>> how this usage causes problems, but I'm still not convinced  
>>>>>> extending the prop table is the right way to handle this.
>>>>>>
>>>>>> -Naama
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> WhatsUp Gold - Download Free Network Management Software
>>>>>> The most intuitive, comprehensive, and cost-effective network
>>>>>> management toolset available today.  Delivers lowest initial
>>>>>> acquisition cost and overall TCO of any competing solution.
>>>>>> http://p.sf.net/sfu/whatsupgold-sd
>>>>>> _______________________________________________
>>>>>> Gmod-phendiver mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Achieve unprecedented app performance and reliability
>>>> What every C/C++ and Fortran developer should know.
>>>> Learn how Intel has extended the reach of its next-generation tools
>>>> to help boost performance applications - inlcuding clusters.
>>>> http://p.sf.net/sfu/intel-dev2devmay
>>>> _______________________________________________
>>>> Gmod-phendiver mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> vRanger cuts backup time in half-while increasing security.
>>> With the market-leading solution for virtual backup and recovery,
>>> you get blazing-fast, flexible, and affordable data protection.
>>> Download your free trial now.
>>> http://p.sf.net/sfu/quest-d2dcopy1
>>> _______________________________________________
>>> Gmod-phendiver mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>>
>> --
>> ===========================================================
>> : Hilmar Lapp -:- Durham, NC -:- hlapp at drycafe dot net :
>> ===========================================================
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> vRanger cuts backup time in half-while increasing security.
>> With the market-leading solution for virtual backup and recovery,
>> you get blazing-fast, flexible, and affordable data protection.
>> Download your free trial now.
>> http://p.sf.net/sfu/quest-d2dcopy1
>> _______________________________________________
>> Gmod-phendiver mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
>


------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

Robert Buels
So, we'll be using Skype, I guess?

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

Naama Menda
no, it's a phone conf.
Seth sent the details a couple of days ago:



Date: Thursday, May 26, 2011
Starting time:   1:00 pm, Eastern Daylight Time

Teleconference:
Call-in toll-free number (US/Canada):                  <a href="tel:1-866-469-3239" value="+18664693239">1-866-469-3239
Call-in toll number (US/Canada):                            <a href="tel:1-650-429-3300" value="+16504293300">1-650-429-3300
Call-in toll number (US/Canada)*:                         <a href="tel:1-408-856-9570" value="+14088569570">1-408-856-9570

Greece toll free:                                                        00800-12-6759
UK toll:                                                                        44 <a href="tel:%280%29%20207%20365%201860" value="+12073651860">(0) 207 365 1860
UK toll free:                                                                    0800-028-8023

ATTENDEE ACCESS CODE: 21813838



Naama Menda
Boyce Thompson Institute for Plant Research
Tower Rd
Ithaca NY 14853
USA

(607) 254 3569
Sol Genomics Network
http://solgenomics.net/
[hidden email]


On Thu, May 26, 2011 at 12:49 PM, Robert Buels <[hidden email]> wrote:
So, we'll be using Skype, I guess?

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver


------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-phendiver] [Gmod-schema] Proposed changes to NatDiv related modules

Maren Friesen
In reply to this post by Robert Buels
Fine with me, who will initiate?

On Thu, May 26, 2011 at 9:49 AM, Robert Buels <[hidden email]> wrote:
So, we'll be using Skype, I guess?

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver



--
Maren Friesen
Postdoctoral Research Associate
Dept of Molecular and Computational Biology
University of Southern California
1050 Child's Way RRI 201-B, Los Angeles, 90089
Phone: 213-741-2858 || Fax: 213-740-8631

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Gmod-phendiver mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-phendiver
12