cv relationships

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

cv relationships

Sanjuro Jogdeo

Hello, 

I'm starting to load plant collection data into chado through a Tripal bulk loader.  I'm a little bit confused about how to enter the country and state/province where the collection took place.  My initial setup was to create cvterms called country and province and create entries in the nd_geolocationprop table for each collection with the value as the country or state/province name and the type_id as either country or state/province.

But I'm wondering if instead I should be loading the country and province names into a cv and referencing them from the nd_geolocationprop table.  I'd prefer the first option, since it is easier but I am interested in knowing what the correct way of doing it would be.  Or doesn't it matter?

I looked around for an obo file for the ISO country/province values and I didn't see anything so I think I would have to create my own obo file.  And in the nd_geolocationprop table, what would the value field be set to if they cv_termid points to a specific country name?

Any suggestions would be welcome.  

Thanks!

Sanjuro

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Bob MacCallum
Hi Sanjuro,

It's possible that the GAZ (Gazetteer) ontology may contain the terms you need.  It's difficult to find info about GAZ and its maintenance, but we (VectorBase) did find some problems with it (circular paths, mainly) which we were able to get cleaned up by the maintainers in 2012 - and it seems that this (1.51+) is now available on bioportal.  Loading GAZ can be a pain, but if you convert to chado-xml and load with stag-storenode.pl it is doable in hours rather than days.

You could then add the GAZ terms as nd_geolocationprops (prop.type = GAZ term, prop.value = NULL)

The only problem with this (and Chado props tables in general) is that what if you want to store another kind of prop for example (prop.type = "human population density cvterm", prop.value = 123.4) then you now have a mixture of key-value and value only (but stored in the key field!) data which might be a pain for your business logic.

We hacked (at the API level, not in the database schema) a way to do key-value pairs where key and value can both be cvterms -
possibly best demonstrated by the unit test code:
https://github.com/bobular/VBPopBio/blob/master/api/Bio-Chado-VBPopBio/t/06-multiprop.t
but you probably don't want to go there!

When you ask what's the correct way of doing it, you have to think about end uses for the database - do you need to search on broader geographic areas*?  If you go the GAZ route, you'll probably want to populate cvtermpath also - we found it only sensible to do this on-the-fly for GAZ (it is so huge) - again using our API layer.  Get back to me if I can help further.

* https://www.vectorbase.org/search/site/%22West%20Africa%22?&site=%22Population%20Biology%22


cheers,
Bob



On Wed, Dec 18, 2013 at 12:13 AM, Sanjuro Jogdeo <[hidden email]> wrote:

Hello, 

I'm starting to load plant collection data into chado through a Tripal bulk loader.  I'm a little bit confused about how to enter the country and state/province where the collection took place.  My initial setup was to create cvterms called country and province and create entries in the nd_geolocationprop table for each collection with the value as the country or state/province name and the type_id as either country or state/province.

But I'm wondering if instead I should be loading the country and province names into a cv and referencing them from the nd_geolocationprop table.  I'd prefer the first option, since it is easier but I am interested in knowing what the correct way of doing it would be.  Or doesn't it matter?

I looked around for an obo file for the ISO country/province values and I didn't see anything so I think I would have to create my own obo file.  And in the nd_geolocationprop table, what would the value field be set to if they cv_termid points to a specific country name?

Any suggestions would be welcome.  

Thanks!

Sanjuro

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema



------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Karl O. Pinc
On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:

> When you ask what's the correct way of doing it, you have to think
> about
> end uses for the database - do you need to search on broader
> geographic
> areas*?

An off-hand, un-informed comment:

If I wanted to search geographic areas I'd try to involve
Postgis because that's what it's for.



Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Sanjuro Jogdeo
Thanks for the suggestions!  GAZ does look like it has the ISO codes we need but also a ton we don't need.  I think I'm going to go with my original plan of just two cvterm ids and nd_geolocationprop values for the country and province names.  We're already using a pre-processing script to validate country and province names so we hopefully won't get invalid names.  All of the rest of the properties will be key value pairs so it might simplify queries as well. 

Thanks so much for the input!  

Sanjuro


On Wed, Dec 18, 2013 at 9:20 AM, Karl O. Pinc <[hidden email]> wrote:
On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:

> When you ask what's the correct way of doing it, you have to think
> about
> end uses for the database - do you need to search on broader
> geographic
> areas*?

An off-hand, un-informed comment:

If I wanted to search geographic areas I'd try to involve
Postgis because that's what it's for.



Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Suzanna Lewis-2
But you will use the GAZ IDs? (even if you don't load the entire thing).

It would make it so very much easier for the community if you didn't use raw strings or invent y.a. ID system.

-S

On Dec 19, 2013, at 10:31 AM, Sanjuro Jogdeo <[hidden email]> wrote:

Thanks for the suggestions!  GAZ does look like it has the ISO codes we need but also a ton we don't need.  I think I'm going to go with my original plan of just two cvterm ids and nd_geolocationprop values for the country and province names.  We're already using a pre-processing script to validate country and province names so we hopefully won't get invalid names.  All of the rest of the properties will be key value pairs so it might simplify queries as well. 

Thanks so much for the input!  

Sanjuro


On Wed, Dec 18, 2013 at 9:20 AM, Karl O. Pinc <[hidden email]> wrote:
On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:

> When you ask what's the correct way of doing it, you have to think
> about
> end uses for the database - do you need to search on broader
> geographic
> areas*?

An off-hand, un-informed comment:

If I wanted to search geographic areas I'd try to involve
Postgis because that's what it's for.



Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Sanjuro Jogdeo
A good point but looking at the GAZ entries more closely, there are many states/provinces that do not follow the ISO standard that we have used to date.  We have the latitude and longitude associated with each collection and if needed, the community can make region inferences from those.

s


On Thu, Dec 19, 2013 at 10:42 AM, Suzanna Lewis <[hidden email]> wrote:
But you will use the GAZ IDs? (even if you don't load the entire thing).

It would make it so very much easier for the community if you didn't use raw strings or invent y.a. ID system.

-S

On Dec 19, 2013, at 10:31 AM, Sanjuro Jogdeo <[hidden email]> wrote:

Thanks for the suggestions!  GAZ does look like it has the ISO codes we need but also a ton we don't need.  I think I'm going to go with my original plan of just two cvterm ids and nd_geolocationprop values for the country and province names.  We're already using a pre-processing script to validate country and province names so we hopefully won't get invalid names.  All of the rest of the properties will be key value pairs so it might simplify queries as well. 

Thanks so much for the input!  

Sanjuro


On Wed, Dec 18, 2013 at 9:20 AM, Karl O. Pinc <[hidden email]> wrote:
On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:

> When you ask what's the correct way of doing it, you have to think
> about
> end uses for the database - do you need to search on broader
> geographic
> areas*?

An off-hand, un-informed comment:

If I wanted to search geographic areas I'd try to involve
Postgis because that's what it's for.



Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema



------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Suzanna Lewis-2
Hi Sanjura,

Actually, what would be ideal is that you add what's missing to GAZ. That way the shared community would have these available and it would not require everyone to repeatedly make those inferences individually for themselves alone. The idea behind all of the ontologies is to work collaboratively to incrementally improve these commonly held resources. Every time someone finds a hole or error and consequently decides to roll their own there can't be further progress. The ontologies are akin to any open source software project - just as GMOD provides a foundation to work upon, same here.

Be nice to see convergence rather than divergence.  

-S 
On Dec 19, 2013, at 12:53 PM, Sanjuro Jogdeo <[hidden email]> wrote:

A good point but looking at the GAZ entries more closely, there are many states/provinces that do not follow the ISO standard that we have used to date.  We have the latitude and longitude associated with each collection and if needed, the community can make region inferences from those.

s


On Thu, Dec 19, 2013 at 10:42 AM, Suzanna Lewis <[hidden email]> wrote:
But you will use the GAZ IDs? (even if you don't load the entire thing).

It would make it so very much easier for the community if you didn't use raw strings or invent y.a. ID system.

-S

On Dec 19, 2013, at 10:31 AM, Sanjuro Jogdeo <[hidden email]> wrote:

Thanks for the suggestions!  GAZ does look like it has the ISO codes we need but also a ton we don't need.  I think I'm going to go with my original plan of just two cvterm ids and nd_geolocationprop values for the country and province names.  We're already using a pre-processing script to validate country and province names so we hopefully won't get invalid names.  All of the rest of the properties will be key value pairs so it might simplify queries as well. 

Thanks so much for the input!  

Sanjuro


On Wed, Dec 18, 2013 at 9:20 AM, Karl O. Pinc <[hidden email]> wrote:
On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:

> When you ask what's the correct way of doing it, you have to think
> about
> end uses for the database - do you need to search on broader
> geographic
> areas*?

An off-hand, un-informed comment:

If I wanted to search geographic areas I'd try to involve
Postgis because that's what it's for.



Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Bob MacCallum



On Thu, Dec 19, 2013 at 10:30 PM, Suzanna Lewis <[hidden email]> wrote:
Hi Sanjura,

Actually, what would be ideal is that you add what's missing to GAZ. That way the shared community would have these available and it would not require everyone to repeatedly make those inferences individually for themselves alone. The

indeed, but how?  In the past (and also just now) I've never been able to find an up to date web presence for GAZ.  My colleagues have contacts with the GAZ developers and so we've been able to request some changes, but shouldn't the whole thing just be on github so we can contribute in a more transparent way?
 
idea behind all of the ontologies is to work collaboratively to incrementally improve these commonly held resources. Every time someone finds a hole or error and consequently decides to roll their own there can't be further progress. The ontologies are akin to any open source software project - just as GMOD provides a foundation to work upon, same here.

Be nice to see convergence rather than divergence.  

-S 

On Dec 19, 2013, at 12:53 PM, Sanjuro Jogdeo <[hidden email]> wrote:

A good point but looking at the GAZ entries more closely, there are many states/provinces that do not follow the ISO standard that we have used to date.  We have the latitude and longitude associated with each collection and if needed, the community can make region inferences from those.

s


On Thu, Dec 19, 2013 at 10:42 AM, Suzanna Lewis <[hidden email]> wrote:
But you will use the GAZ IDs? (even if you don't load the entire thing).

It would make it so very much easier for the community if you didn't use raw strings or invent y.a. ID system.

-S

On Dec 19, 2013, at 10:31 AM, Sanjuro Jogdeo <[hidden email]> wrote:

Thanks for the suggestions!  GAZ does look like it has the ISO codes we need but also a ton we don't need.  I think I'm going to go with my original plan of just two cvterm ids and nd_geolocationprop values for the country and province names.  We're already using a pre-processing script to validate country and province names so we hopefully won't get invalid names.  All of the rest of the properties will be key value pairs so it might simplify queries as well. 

Thanks so much for the input!  

Sanjuro


On Wed, Dec 18, 2013 at 9:20 AM, Karl O. Pinc <[hidden email]> wrote:
On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:

> When you ask what's the correct way of doing it, you have to think
> about
> end uses for the database - do you need to search on broader
> geographic
> areas*?

An off-hand, un-informed comment:

If I wanted to search geographic areas I'd try to involve
Postgis because that's what it's for.



Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema



------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Suzanna Lewis-2
I agree as well. That's the first (and essential) first step.

Michael (copied here) is the primary content person, but he is now officially retired. He's still interested in GAZ, but to be honest its care and content needs to be brought into the modern age. Moving it to github (or equivalent) is essential operationally to keep it Open. Make it so that it's easier for other people to work on it as well.

I know it ran into problems with SVN because of the file size. Chris M. can speak to that.

I'll try and do what I can to help out because it'd be a shame to throw years of effort away. Let me see what I can do.

Plus you're in London? Same time zone as Michael, perhaps arrange a call with him?

-S

On Dec 19, 2013, at 3:03 PM, Bob MacCallum <[hidden email]> wrote:




On Thu, Dec 19, 2013 at 10:30 PM, Suzanna Lewis <[hidden email]> wrote:
Hi Sanjura,

Actually, what would be ideal is that you add what's missing to GAZ. That way the shared community would have these available and it would not require everyone to repeatedly make those inferences individually for themselves alone. The

indeed, but how?  In the past (and also just now) I've never been able to find an up to date web presence for GAZ.  My colleagues have contacts with the GAZ developers and so we've been able to request some changes, but shouldn't the whole thing just be on github so we can contribute in a more transparent way?
 
idea behind all of the ontologies is to work collaboratively to incrementally improve these commonly held resources. Every time someone finds a hole or error and consequently decides to roll their own there can't be further progress. The ontologies are akin to any open source software project - just as GMOD provides a foundation to work upon, same here.

Be nice to see convergence rather than divergence.  
-S 

On Dec 19, 2013, at 12:53 PM, Sanjuro Jogdeo <[hidden email]> wrote:

A good point but looking at the GAZ entries more closely, there are many states/provinces that do not follow the ISO standard that we have used to date.  We have the latitude and longitude associated with each collection and if needed, the community can make region inferences from those.

s


On Thu, Dec 19, 2013 at 10:42 AM, Suzanna Lewis <[hidden email]> wrote:
But you will use the GAZ IDs? (even if you don't load the entire thing).

It would make it so very much easier for the community if you didn't use raw strings or invent y.a. ID system.

-S

On Dec 19, 2013, at 10:31 AM, Sanjuro Jogdeo <[hidden email]> wrote:

Thanks for the suggestions!  GAZ does look like it has the ISO codes we need but also a ton we don't need.  I think I'm going to go with my original plan of just two cvterm ids and nd_geolocationprop values for the country and province names.  We're already using a pre-processing script to validate country and province names so we hopefully won't get invalid names.  All of the rest of the properties will be key value pairs so it might simplify queries as well. 

Thanks so much for the input!  

Sanjuro


On Wed, Dec 18, 2013 at 9:20 AM, Karl O. Pinc <[hidden email]> wrote:
On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:

> When you ask what's the correct way of doing it, you have to think
> about
> end uses for the database - do you need to search on broader
> geographic
> areas*?

An off-hand, un-informed comment:

If I wanted to search geographic areas I'd try to involve
Postgis because that's what it's for.



Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Suzanna Lewis-2
p.s. I think the only Web presence is under obo (http://obofoundry.org/cgi-bin/detail.cgi?id=gazetteer) or envo (http://environmentontology.org/)

On Dec 19, 2013, at 3:34 PM, Suzanna Lewis <[hidden email]> wrote:

I agree as well. That's the first (and essential) first step.

Michael (copied here) is the primary content person, but he is now officially retired. He's still interested in GAZ, but to be honest its care and content needs to be brought into the modern age. Moving it to github (or equivalent) is essential operationally to keep it Open. Make it so that it's easier for other people to work on it as well.

I know it ran into problems with SVN because of the file size. Chris M. can speak to that.

I'll try and do what I can to help out because it'd be a shame to throw years of effort away. Let me see what I can do.

Plus you're in London? Same time zone as Michael, perhaps arrange a call with him?

-S

On Dec 19, 2013, at 3:03 PM, Bob MacCallum <[hidden email]> wrote:




On Thu, Dec 19, 2013 at 10:30 PM, Suzanna Lewis <[hidden email]> wrote:
Hi Sanjura,

Actually, what would be ideal is that you add what's missing to GAZ. That way the shared community would have these available and it would not require everyone to repeatedly make those inferences individually for themselves alone. The

indeed, but how?  In the past (and also just now) I've never been able to find an up to date web presence for GAZ.  My colleagues have contacts with the GAZ developers and so we've been able to request some changes, but shouldn't the whole thing just be on github so we can contribute in a more transparent way?
 
idea behind all of the ontologies is to work collaboratively to incrementally improve these commonly held resources. Every time someone finds a hole or error and consequently decides to roll their own there can't be further progress. The ontologies are akin to any open source software project - just as GMOD provides a foundation to work upon, same here.

Be nice to see convergence rather than divergence.  
-S 

On Dec 19, 2013, at 12:53 PM, Sanjuro Jogdeo <[hidden email]> wrote:

A good point but looking at the GAZ entries more closely, there are many states/provinces that do not follow the ISO standard that we have used to date.  We have the latitude and longitude associated with each collection and if needed, the community can make region inferences from those.

s


On Thu, Dec 19, 2013 at 10:42 AM, Suzanna Lewis <[hidden email]> wrote:
But you will use the GAZ IDs? (even if you don't load the entire thing).

It would make it so very much easier for the community if you didn't use raw strings or invent y.a. ID system.

-S

On Dec 19, 2013, at 10:31 AM, Sanjuro Jogdeo <[hidden email]> wrote:

Thanks for the suggestions!  GAZ does look like it has the ISO codes we need but also a ton we don't need.  I think I'm going to go with my original plan of just two cvterm ids and nd_geolocationprop values for the country and province names.  We're already using a pre-processing script to validate country and province names so we hopefully won't get invalid names.  All of the rest of the properties will be key value pairs so it might simplify queries as well. 

Thanks so much for the input!  

Sanjuro


On Wed, Dec 18, 2013 at 9:20 AM, Karl O. Pinc <[hidden email]> wrote:
On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:

> When you ask what's the correct way of doing it, you have to think
> about
> end uses for the database - do you need to search on broader
> geographic
> areas*?

An off-hand, un-informed comment:

If I wanted to search geographic areas I'd try to involve
Postgis because that's what it's for.



Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema





------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Bob MacCallum
Great thanks Suzanna, yes let's get the ball rolling to open up maintenance.

I hadn't thought about file size limits, but 50MB/100MB is the soft/hard limit at github
https://help.github.com/articles/working-with-large-files
and the 1.51 obo file was 135MB so we have to figure something some workable alternative.

The overall repository size shouldn't be a problem (1GB is the recommended max)




On Thu, Dec 19, 2013 at 11:37 PM, Suzanna Lewis <[hidden email]> wrote:
p.s. I think the only Web presence is under obo (http://obofoundry.org/cgi-bin/detail.cgi?id=gazetteer) or envo (http://environmentontology.org/)

On Dec 19, 2013, at 3:34 PM, Suzanna Lewis <[hidden email]> wrote:

I agree as well. That's the first (and essential) first step.

Michael (copied here) is the primary content person, but he is now officially retired. He's still interested in GAZ, but to be honest its care and content needs to be brought into the modern age. Moving it to github (or equivalent) is essential operationally to keep it Open. Make it so that it's easier for other people to work on it as well.

I know it ran into problems with SVN because of the file size. Chris M. can speak to that.

I'll try and do what I can to help out because it'd be a shame to throw years of effort away. Let me see what I can do.

Plus you're in London? Same time zone as Michael, perhaps arrange a call with him?

-S

On Dec 19, 2013, at 3:03 PM, Bob MacCallum <[hidden email]> wrote:




On Thu, Dec 19, 2013 at 10:30 PM, Suzanna Lewis <[hidden email]> wrote:
Hi Sanjura,

Actually, what would be ideal is that you add what's missing to GAZ. That way the shared community would have these available and it would not require everyone to repeatedly make those inferences individually for themselves alone. The

indeed, but how?  In the past (and also just now) I've never been able to find an up to date web presence for GAZ.  My colleagues have contacts with the GAZ developers and so we've been able to request some changes, but shouldn't the whole thing just be on github so we can contribute in a more transparent way?
 
idea behind all of the ontologies is to work collaboratively to incrementally improve these commonly held resources. Every time someone finds a hole or error and consequently decides to roll their own there can't be further progress. The ontologies are akin to any open source software project - just as GMOD provides a foundation to work upon, same here.

Be nice to see convergence rather than divergence.  
-S 

On Dec 19, 2013, at 12:53 PM, Sanjuro Jogdeo <[hidden email]> wrote:

A good point but looking at the GAZ entries more closely, there are many states/provinces that do not follow the ISO standard that we have used to date.  We have the latitude and longitude associated with each collection and if needed, the community can make region inferences from those.

s


On Thu, Dec 19, 2013 at 10:42 AM, Suzanna Lewis <[hidden email]> wrote:
But you will use the GAZ IDs? (even if you don't load the entire thing).

It would make it so very much easier for the community if you didn't use raw strings or invent y.a. ID system.

-S

On Dec 19, 2013, at 10:31 AM, Sanjuro Jogdeo <[hidden email]> wrote:

Thanks for the suggestions!  GAZ does look like it has the ISO codes we need but also a ton we don't need.  I think I'm going to go with my original plan of just two cvterm ids and nd_geolocationprop values for the country and province names.  We're already using a pre-processing script to validate country and province names so we hopefully won't get invalid names.  All of the rest of the properties will be key value pairs so it might simplify queries as well. 

Thanks so much for the input!  

Sanjuro


On Wed, Dec 18, 2013 at 9:20 AM, Karl O. Pinc <[hidden email]> wrote:
On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:

> When you ask what's the correct way of doing it, you have to think
> about
> end uses for the database - do you need to search on broader
> geographic
> areas*?

An off-hand, un-informed comment:

If I wanted to search geographic areas I'd try to involve
Postgis because that's what it's for.



Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema






------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Scott Cain
I'm completely unfamiliar with GAZ, but would it be possible to break it into logical chunks?  A simple script could be written (notice the passive voice :-) that would assemble them for releases or working with locallly (though then I suppose you'd need a script to break them back apart for committing).  Ugh.  May not be a great solution, but it could work if nothing else comes along.

Scott



On Fri, Dec 20, 2013 at 5:32 AM, Bob MacCallum <[hidden email]> wrote:
Great thanks Suzanna, yes let's get the ball rolling to open up maintenance.

I hadn't thought about file size limits, but 50MB/100MB is the soft/hard limit at github
https://help.github.com/articles/working-with-large-files
and the 1.51 obo file was 135MB so we have to figure something some workable alternative.

The overall repository size shouldn't be a problem (1GB is the recommended max)




On Thu, Dec 19, 2013 at 11:37 PM, Suzanna Lewis <[hidden email]> wrote:
p.s. I think the only Web presence is under obo (http://obofoundry.org/cgi-bin/detail.cgi?id=gazetteer) or envo (http://environmentontology.org/)

On Dec 19, 2013, at 3:34 PM, Suzanna Lewis <[hidden email]> wrote:

I agree as well. That's the first (and essential) first step.

Michael (copied here) is the primary content person, but he is now officially retired. He's still interested in GAZ, but to be honest its care and content needs to be brought into the modern age. Moving it to github (or equivalent) is essential operationally to keep it Open. Make it so that it's easier for other people to work on it as well.

I know it ran into problems with SVN because of the file size. Chris M. can speak to that.

I'll try and do what I can to help out because it'd be a shame to throw years of effort away. Let me see what I can do.

Plus you're in London? Same time zone as Michael, perhaps arrange a call with him?

-S

On Dec 19, 2013, at 3:03 PM, Bob MacCallum <[hidden email]> wrote:




On Thu, Dec 19, 2013 at 10:30 PM, Suzanna Lewis <[hidden email]> wrote:
Hi Sanjura,

Actually, what would be ideal is that you add what's missing to GAZ. That way the shared community would have these available and it would not require everyone to repeatedly make those inferences individually for themselves alone. The

indeed, but how?  In the past (and also just now) I've never been able to find an up to date web presence for GAZ.  My colleagues have contacts with the GAZ developers and so we've been able to request some changes, but shouldn't the whole thing just be on github so we can contribute in a more transparent way?
 
idea behind all of the ontologies is to work collaboratively to incrementally improve these commonly held resources. Every time someone finds a hole or error and consequently decides to roll their own there can't be further progress. The ontologies are akin to any open source software project - just as GMOD provides a foundation to work upon, same here.

Be nice to see convergence rather than divergence.  
-S 

On Dec 19, 2013, at 12:53 PM, Sanjuro Jogdeo <[hidden email]> wrote:

A good point but looking at the GAZ entries more closely, there are many states/provinces that do not follow the ISO standard that we have used to date.  We have the latitude and longitude associated with each collection and if needed, the community can make region inferences from those.

s


On Thu, Dec 19, 2013 at 10:42 AM, Suzanna Lewis <[hidden email]> wrote:
But you will use the GAZ IDs? (even if you don't load the entire thing).

It would make it so very much easier for the community if you didn't use raw strings or invent y.a. ID system.

-S

On Dec 19, 2013, at 10:31 AM, Sanjuro Jogdeo <[hidden email]> wrote:

Thanks for the suggestions!  GAZ does look like it has the ISO codes we need but also a ton we don't need.  I think I'm going to go with my original plan of just two cvterm ids and nd_geolocationprop values for the country and province names.  We're already using a pre-processing script to validate country and province names so we hopefully won't get invalid names.  All of the rest of the properties will be key value pairs so it might simplify queries as well. 

Thanks so much for the input!  

Sanjuro


On Wed, Dec 18, 2013 at 9:20 AM, Karl O. Pinc <[hidden email]> wrote:
On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:

> When you ask what's the correct way of doing it, you have to think
> about
> end uses for the database - do you need to search on broader
> geographic
> areas*?

An off-hand, un-informed comment:

If I wanted to search geographic areas I'd try to involve
Postgis because that's what it's for.



Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema






------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




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

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Karl O. Pinc
On 12/20/2013 09:55:12 AM, Scott Cain wrote:

> I'm completely unfamiliar with GAZ, but would it be possible to break
> it
> into logical chunks?  A simple script could be written (notice the
> passive
> voice :-) that would assemble them for releases or working with
> locallly
> (though then I suppose you'd need a script to break them back apart
> for
> committing).  Ugh.  May not be a great solution, but it could work if
> nothing else comes along.

It looks trivial to break into pieces by term.  And, after
a glance at the syntax, the file format seems term-order
independent so reassembly wouldn't even have to preserve
order.

The problem is in making something that works cross-platform.
Rather than try, it's probably better to have some sort of
build system running on a web-accessible host.  This would
make available (dynamically?) pre-assembled .obo file(s).

But that just re-introduces the original problem.  How
to host it?  :-P

Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Siddhartha Basu
In reply to this post by Scott Cain
Just wondering how the sequence ontology(SO) accepts community
contribution, could GAZ be maintained that way. And generally speaking
how do most of the popular ontology manages community patches
anyway(expect GO which has a well defined structure).
On a related note, i remember somebody hit the github file limit while
trying to migrate chado repository from svn to github.

Another alternate would be bitbucket
https://bitbucket.org/ and it might be possible to put a large file.
https://confluence.atlassian.com/pages/viewpage.action?pageId=273877699

Now since git might have issues with large file handling,
in that case we need a publicly accessible web remote(through ssh) and
use git-annex(http://git-annex.branchable.com/) on it. We will of course
miss the Web management UI like github/bitbucket.

thanks,
-siddhartha

On Fri, 20 Dec 2013, Scott Cain wrote:

>    I'm completely unfamiliar with GAZ, but would it be possible to break it
>    into logical chunks?  A simple script could be written (notice the passive
>    voice :-) that would assemble them for releases or working with locallly
>    (though then I suppose you'd need a script to break them back apart for
>    committing).  Ugh.  May not be a great solution, but it could work if
>    nothing else comes along.
>    Scott
>
>    On Fri, Dec 20, 2013 at 5:32 AM, Bob MacCallum
>    <[hidden email]> wrote:
>
>      Great thanks Suzanna, yes let's get the ball rolling to open up
>      maintenance.
>
>      I hadn't thought about file size limits, but 50MB/100MB is the soft/hard
>      limit at github
>      https://help.github.com/articles/working-with-large-files
>      and the 1.51 obo file was 135MB so we have to figure something some
>      workable alternative.
>
>      The overall repository size shouldn't be a problem (1GB is the
>      recommended max)
>
>      On Thu, Dec 19, 2013 at 11:37 PM, Suzanna Lewis <[hidden email]>
>      wrote:
>
>        p.s. I think the only Web presence is under obo
>        (http://obofoundry.org/cgi-bin/detail.cgi?id=gazetteer) or envo
>        (http://environmentontology.org/)
>        On Dec 19, 2013, at 3:34 PM, Suzanna Lewis <[hidden email]>
>        wrote:
>
>          I agree as well. That's the first (and essential) first step.
>          Michael (copied here) is the primary content person, but he is now
>          officially retired. He's still interested in GAZ, but to be honest
>          its care and content needs to be brought into the modern age. Moving
>          it to github (or equivalent) is essential operationally to keep it
>          Open. Make it so that it's easier for other people to work on it as
>          well.
>          I know it ran into problems with SVN because of the file size. Chris
>          M. can speak to that.
>          I'll try and do what I can to help out because it'd be a shame to
>          throw years of effort away. Let me see what I can do.
>          Plus you're in London? Same time zone as Michael, perhaps arrange a
>          call with him?
>          -S
>          On Dec 19, 2013, at 3:03 PM, Bob MacCallum
>          <[hidden email]> wrote:
>
>            On Thu, Dec 19, 2013 at 10:30 PM, Suzanna Lewis
>            <[hidden email]> wrote:
>
>              Hi Sanjura,
>              Actually, what would be ideal is that you add what's missing to
>              GAZ. That way the shared community would have these available
>              and it would not require everyone to repeatedly make those
>              inferences individually for themselves alone. The
>
>            indeed, but how?  In the past (and also just now) I've never been
>            able to find an up to date web presence for GAZ.  My colleagues
>            have contacts with the GAZ developers and so we've been able to
>            request some changes, but shouldn't the whole thing just be on
>            github so we can contribute in a more transparent way?
>            
>
>              idea behind all of the ontologies is to work collaboratively to
>              incrementally improve these commonly held resources. Every time
>              someone finds a hole or error and consequently decides to roll
>              their own there can't be further progress. The ontologies are
>              akin to any open source software project - just as GMOD provides
>              a foundation to work upon, same here.
>              Be nice to see convergence rather than divergence.  
>              -S
>              On Dec 19, 2013, at 12:53 PM, Sanjuro Jogdeo
>              <[hidden email]> wrote:
>
>                A good point but looking at the GAZ entries more closely,
>                there are many states/provinces that do not follow the ISO
>                standard that we have used to date.  We have the latitude and
>                longitude associated with each collection and if needed, the
>                community can make region inferences from those.
>                s
>
>                On Thu, Dec 19, 2013 at 10:42 AM, Suzanna Lewis
>                <[hidden email]> wrote:
>
>                  But you will use the GAZ IDs? (even if you don't load the
>                  entire thing).
>                  It would make it so very much easier for the community if
>                  you didn't use raw strings or invent y.a. ID system.
>                  -S
>                  On Dec 19, 2013, at 10:31 AM, Sanjuro Jogdeo
>                  <[hidden email]> wrote:
>
>                    Thanks for the suggestions!  GAZ does look like it has the
>                    ISO codes we need but also a ton we don't need.  I think
>                    I'm going to go with my original plan of just two cvterm
>                    ids and nd_geolocationprop values for the country and
>                    province names.  We're already using a pre-processing
>                    script to validate country and province names so we
>                    hopefully won't get invalid names.  All of the rest of the
>                    properties will be key value pairs so it might simplify
>                    queries as well.
>                    Thanks so much for the input!  
>                    Sanjuro
>
>                    On Wed, Dec 18, 2013 at 9:20 AM, Karl O. Pinc
>                    <[hidden email]> wrote:
>
>                      On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:
>
>                      > When you ask what's the correct way of doing it, you
>                      have to think
>                      > about
>                      > end uses for the database - do you need to search on
>                      broader
>                      > geographic
>                      > areas*?
>
>                      An off-hand, un-informed comment:
>
>                      If I wanted to search geographic areas I'd try to
>                      involve
>                      Postgis because that's what it's for.
>
>                      Karl <[hidden email]>
>                      Free Software:  "You don't pay back, you pay forward."
>                                       -- Robert A. Heinlein
>                      ------------------------------------------------------------------------------
>                      Rapidly troubleshoot problems before they affect your
>                      business. Most IT
>                      organizations don't have a clear picture of how
>                      application performance
>                      affects their revenue. With AppDynamics, you get 100%
>                      visibility into your
>                      Java,.NET, & PHP application. Start your 15-day FREE
>                      TRIAL of AppDynamics Pro!
>                      http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>                      _______________________________________________
>                      Gmod-schema mailing list
>                      [hidden email]
>                      https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>                    ------------------------------------------------------------------------------
>                    Rapidly troubleshoot problems before they affect your
>                    business. Most IT
>                    organizations don't have a clear picture of how
>                    application performance
>                    affects their revenue. With AppDynamics, you get 100%
>                    visibility into your
>                    Java,.NET, & PHP application. Start your 15-day FREE TRIAL
>                    of AppDynamics Pro!
>                    http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
>                    Gmod-schema mailing list
>                    [hidden email]
>                    https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>              ------------------------------------------------------------------------------
>              Rapidly troubleshoot problems before they affect your business.
>              Most IT
>              organizations don't have a clear picture of how application
>              performance
>              affects their revenue. With AppDynamics, you get 100% visibility
>              into your
>              Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>              AppDynamics Pro!
>              http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>              _______________________________________________
>              Gmod-schema mailing list
>              [hidden email]
>              https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>      ------------------------------------------------------------------------------
>      Rapidly troubleshoot problems before they affect your business. Most IT
>      organizations don't have a clear picture of how application performance
>      affects their revenue. With AppDynamics, you get 100% visibility into
>      your
>      Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>      AppDynamics Pro!
>      http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>      _______________________________________________
>      Gmod-schema mailing list
>      [hidden email]
>      https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>    --
>    ------------------------------------------------------------------------
>    Scott Cain, Ph. D.                                   scott at scottcain
>    dot net
>    GMOD Coordinator (http://gmod.org/)                     216-392-3087
>    Ontario Institute for Cancer Research

> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk

> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Scott Cain
Chado is still in svn... :-)


On Fri, Dec 20, 2013 at 12:03 PM, Siddhartha Basu <[hidden email]> wrote:
Just wondering how the sequence ontology(SO) accepts community
contribution, could GAZ be maintained that way. And generally speaking
how do most of the popular ontology manages community patches
anyway(expect GO which has a well defined structure).
On a related note, i remember somebody hit the github file limit while
trying to migrate chado repository from svn to github.

Another alternate would be bitbucket
https://bitbucket.org/ and it might be possible to put a large file.
https://confluence.atlassian.com/pages/viewpage.action?pageId=273877699

Now since git might have issues with large file handling,
in that case we need a publicly accessible web remote(through ssh) and
use git-annex(http://git-annex.branchable.com/) on it. We will of course
miss the Web management UI like github/bitbucket.

thanks,
-siddhartha

On Fri, 20 Dec 2013, Scott Cain wrote:

>    I'm completely unfamiliar with GAZ, but would it be possible to break it
>    into logical chunks?  A simple script could be written (notice the passive
>    voice :-) that would assemble them for releases or working with locallly
>    (though then I suppose you'd need a script to break them back apart for
>    committing).  Ugh.  May not be a great solution, but it could work if
>    nothing else comes along.
>    Scott
>
>    On Fri, Dec 20, 2013 at 5:32 AM, Bob MacCallum
>    <[hidden email]> wrote:
>
>      Great thanks Suzanna, yes let's get the ball rolling to open up
>      maintenance.
>
>      I hadn't thought about file size limits, but 50MB/100MB is the soft/hard
>      limit at github
>      https://help.github.com/articles/working-with-large-files
>      and the 1.51 obo file was 135MB so we have to figure something some
>      workable alternative.
>
>      The overall repository size shouldn't be a problem (1GB is the
>      recommended max)
>
>      On Thu, Dec 19, 2013 at 11:37 PM, Suzanna Lewis <[hidden email]>
>      wrote:
>
>        p.s. I think the only Web presence is under obo
>        (http://obofoundry.org/cgi-bin/detail.cgi?id=gazetteer) or envo
>        (http://environmentontology.org/)
>        On Dec 19, 2013, at 3:34 PM, Suzanna Lewis <[hidden email]>
>        wrote:
>
>          I agree as well. That's the first (and essential) first step.
>          Michael (copied here) is the primary content person, but he is now
>          officially retired. He's still interested in GAZ, but to be honest
>          its care and content needs to be brought into the modern age. Moving
>          it to github (or equivalent) is essential operationally to keep it
>          Open. Make it so that it's easier for other people to work on it as
>          well.
>          I know it ran into problems with SVN because of the file size. Chris
>          M. can speak to that.
>          I'll try and do what I can to help out because it'd be a shame to
>          throw years of effort away. Let me see what I can do.
>          Plus you're in London? Same time zone as Michael, perhaps arrange a
>          call with him?
>          -S
>          On Dec 19, 2013, at 3:03 PM, Bob MacCallum
>          <[hidden email]> wrote:
>
>            On Thu, Dec 19, 2013 at 10:30 PM, Suzanna Lewis
>            <[hidden email]> wrote:
>
>              Hi Sanjura,
>              Actually, what would be ideal is that you add what's missing to
>              GAZ. That way the shared community would have these available
>              and it would not require everyone to repeatedly make those
>              inferences individually for themselves alone. The
>
>            indeed, but how?  In the past (and also just now) I've never been
>            able to find an up to date web presence for GAZ.  My colleagues
>            have contacts with the GAZ developers and so we've been able to
>            request some changes, but shouldn't the whole thing just be on
>            github so we can contribute in a more transparent way?
>
>
>              idea behind all of the ontologies is to work collaboratively to
>              incrementally improve these commonly held resources. Every time
>              someone finds a hole or error and consequently decides to roll
>              their own there can't be further progress. The ontologies are
>              akin to any open source software project - just as GMOD provides
>              a foundation to work upon, same here.
>              Be nice to see convergence rather than divergence.
>              -S
>              On Dec 19, 2013, at 12:53 PM, Sanjuro Jogdeo
>              <[hidden email]> wrote:
>
>                A good point but looking at the GAZ entries more closely,
>                there are many states/provinces that do not follow the ISO
>                standard that we have used to date.  We have the latitude and
>                longitude associated with each collection and if needed, the
>                community can make region inferences from those.
>                s
>
>                On Thu, Dec 19, 2013 at 10:42 AM, Suzanna Lewis
>                <[hidden email]> wrote:
>
>                  But you will use the GAZ IDs? (even if you don't load the
>                  entire thing).
>                  It would make it so very much easier for the community if
>                  you didn't use raw strings or invent y.a. ID system.
>                  -S
>                  On Dec 19, 2013, at 10:31 AM, Sanjuro Jogdeo
>                  <[hidden email]> wrote:
>
>                    Thanks for the suggestions!  GAZ does look like it has the
>                    ISO codes we need but also a ton we don't need.  I think
>                    I'm going to go with my original plan of just two cvterm
>                    ids and nd_geolocationprop values for the country and
>                    province names.  We're already using a pre-processing
>                    script to validate country and province names so we
>                    hopefully won't get invalid names.  All of the rest of the
>                    properties will be key value pairs so it might simplify
>                    queries as well.
>                    Thanks so much for the input!
>                    Sanjuro
>
>                    On Wed, Dec 18, 2013 at 9:20 AM, Karl O. Pinc
>                    <[hidden email]> wrote:
>
>                      On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:
>
>                      > When you ask what's the correct way of doing it, you
>                      have to think
>                      > about
>                      > end uses for the database - do you need to search on
>                      broader
>                      > geographic
>                      > areas*?
>
>                      An off-hand, un-informed comment:
>
>                      If I wanted to search geographic areas I'd try to
>                      involve
>                      Postgis because that's what it's for.
>
>                      Karl <[hidden email]>
>                      Free Software:  "You don't pay back, you pay forward."
>                                       -- Robert A. Heinlein
>                      ------------------------------------------------------------------------------
>                      Rapidly troubleshoot problems before they affect your
>                      business. Most IT
>                      organizations don't have a clear picture of how
>                      application performance
>                      affects their revenue. With AppDynamics, you get 100%
>                      visibility into your
>                      Java,.NET, & PHP application. Start your 15-day FREE
>                      TRIAL of AppDynamics Pro!
>                      http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>                      _______________________________________________
>                      Gmod-schema mailing list
>                      [hidden email]
>                      https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>                    ------------------------------------------------------------------------------
>                    Rapidly troubleshoot problems before they affect your
>                    business. Most IT
>                    organizations don't have a clear picture of how
>                    application performance
>                    affects their revenue. With AppDynamics, you get 100%
>                    visibility into your
>                    Java,.NET, & PHP application. Start your 15-day FREE TRIAL
>                    of AppDynamics Pro!
>                    http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
>                    Gmod-schema mailing list
>                    [hidden email]
>                    https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>              ------------------------------------------------------------------------------
>              Rapidly troubleshoot problems before they affect your business.
>              Most IT
>              organizations don't have a clear picture of how application
>              performance
>              affects their revenue. With AppDynamics, you get 100% visibility
>              into your
>              Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>              AppDynamics Pro!
>              http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>              _______________________________________________
>              Gmod-schema mailing list
>              [hidden email]
>              https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>      ------------------------------------------------------------------------------
>      Rapidly troubleshoot problems before they affect your business. Most IT
>      organizations don't have a clear picture of how application performance
>      affects their revenue. With AppDynamics, you get 100% visibility into
>      your
>      Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>      AppDynamics Pro!
>      http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>      _______________________________________________
>      Gmod-schema mailing list
>      [hidden email]
>      https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>    --
>    ------------------------------------------------------------------------
>    Scott Cain, Ph. D.                                   scott at scottcain
>    dot net
>    GMOD Coordinator (http://gmod.org/)                     <a href="tel:216-392-3087" value="+12163923087">216-392-3087
>    Ontario Institute for Cancer Research

> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk

> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema



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

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Karl O. Pinc
The problem is not git, but github.  It's a hosting problem.
The problem goes away with a "better" git hosting provider.

(Not that I'm enamored of git. :-)

On 12/20/2013 11:14:10 AM, Scott Cain wrote:
> Chado is still in svn... :-)
>
>
> On Fri, Dec 20, 2013 at 12:03 PM, Siddhartha Basu <[hidden email]>
> wrote:
>
> > Just wondering how the sequence ontology(SO) accepts community
> > contribution, could GAZ be maintained that way.

Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Suzanna Lewis-2
In reply to this post by Bob MacCallum
Hi Bob,

We've just had Michael put the file into dropbox and Chris M. is updating the obofoundry.org GAZ from there (so that will be the best site to pull if from).

Chris also noticed some syntax errors which he's removed from the public release. He's sent the list of corrections to Michael and hopefully he'll get them patched up quickly.

It would be absolutely fantastic to have you and others keeping the ball rolling on maintenance! Really great. GAZ already has close to 3/4 million place names, so a lot of work would be lost otherwise.

Sidd, yes GAZ could indeed be maintained the same way as SO. The difference is that right now SO has funding and GAZ is in need of someone to take over from Michael. It's simply a matter of someone minding the store and being there to respond to requests.

GAZ and EnvO originated at the same time (place names in GAZ and habitats/biomes in EnvO). EnvO by and large is now maintained by folks in the meta-genomics community (Oxford and Bremen), and is slowly maturing.

Scott and Karl, format is OBO format. (http://www.geneontology.org/GO.format.obo-1_2.shtml) and there are converters to OWL (not sure how lossy these are). I agree it could be broken up, perhaps by continent like gondwanaland. :-)
 
-S

On Dec 20, 2013, at 2:32 AM, Bob MacCallum <[hidden email]> wrote:

Great thanks Suzanna, yes let's get the ball rolling to open up maintenance.

I hadn't thought about file size limits, but 50MB/100MB is the soft/hard limit at github
https://help.github.com/articles/working-with-large-files
and the 1.51 obo file was 135MB so we have to figure something some workable alternative.

The overall repository size shouldn't be a problem (1GB is the recommended max)




On Thu, Dec 19, 2013 at 11:37 PM, Suzanna Lewis <[hidden email]> wrote:
p.s. I think the only Web presence is under obo (http://obofoundry.org/cgi-bin/detail.cgi?id=gazetteer) or envo (http://environmentontology.org/)

On Dec 19, 2013, at 3:34 PM, Suzanna Lewis <[hidden email]> wrote:

I agree as well. That's the first (and essential) first step.

Michael (copied here) is the primary content person, but he is now officially retired. He's still interested in GAZ, but to be honest its care and content needs to be brought into the modern age. Moving it to github (or equivalent) is essential operationally to keep it Open. Make it so that it's easier for other people to work on it as well.

I know it ran into problems with SVN because of the file size. Chris M. can speak to that.

I'll try and do what I can to help out because it'd be a shame to throw years of effort away. Let me see what I can do.

Plus you're in London? Same time zone as Michael, perhaps arrange a call with him?

-S

On Dec 19, 2013, at 3:03 PM, Bob MacCallum <[hidden email]> wrote:




On Thu, Dec 19, 2013 at 10:30 PM, Suzanna Lewis <[hidden email]> wrote:
Hi Sanjura,

Actually, what would be ideal is that you add what's missing to GAZ. That way the shared community would have these available and it would not require everyone to repeatedly make those inferences individually for themselves alone. The

indeed, but how?  In the past (and also just now) I've never been able to find an up to date web presence for GAZ.  My colleagues have contacts with the GAZ developers and so we've been able to request some changes, but shouldn't the whole thing just be on github so we can contribute in a more transparent way?
 
idea behind all of the ontologies is to work collaboratively to incrementally improve these commonly held resources. Every time someone finds a hole or error and consequently decides to roll their own there can't be further progress. The ontologies are akin to any open source software project - just as GMOD provides a foundation to work upon, same here.

Be nice to see convergence rather than divergence.  
-S 

On Dec 19, 2013, at 12:53 PM, Sanjuro Jogdeo <[hidden email]> wrote:

A good point but looking at the GAZ entries more closely, there are many states/provinces that do not follow the ISO standard that we have used to date.  We have the latitude and longitude associated with each collection and if needed, the community can make region inferences from those.

s


On Thu, Dec 19, 2013 at 10:42 AM, Suzanna Lewis <[hidden email]> wrote:
But you will use the GAZ IDs? (even if you don't load the entire thing).

It would make it so very much easier for the community if you didn't use raw strings or invent y.a. ID system.

-S

On Dec 19, 2013, at 10:31 AM, Sanjuro Jogdeo <[hidden email]> wrote:

Thanks for the suggestions!  GAZ does look like it has the ISO codes we need but also a ton we don't need.  I think I'm going to go with my original plan of just two cvterm ids and nd_geolocationprop values for the country and province names.  We're already using a pre-processing script to validate country and province names so we hopefully won't get invalid names.  All of the rest of the properties will be key value pairs so it might simplify queries as well. 

Thanks so much for the input!  

Sanjuro


On Wed, Dec 18, 2013 at 9:20 AM, Karl O. Pinc <[hidden email]> wrote:
On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:

> When you ask what's the correct way of doing it, you have to think
> about
> end uses for the database - do you need to search on broader
> geographic
> areas*?

An off-hand, un-informed comment:

If I wanted to search geographic areas I'd try to involve
Postgis because that's what it's for.



Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema







------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Chris Mungall-5
As Suzi says, the obofoundry site now points to the latest version
http://obofoundry.org/cgi-bin/detail.cgi?id=gazetteer

(I already applied patches to resolve the syntax errors)

We're by passing a version control system at the moment - our continuous integration server grabs the most recent version from Michael's dropbox and creates a release, unless errors are found
(http://build.berkeleybop.org/job/build-gaz/ for those who are interested)

This process also generates an OWL file, using a non-standard obo2owl translation, whereby the "classes" in GAZ are translated to instances, so the OWL version is the 'semantically correct' one (although the OBO version is more convenient for editing).

We're still looking for solutions to modularize GAZ, as this would make it easier both to edit, and to manage in version control. Longer term we may be looking at web-based editing.




On Sat, Dec 21, 2013 at 10:49 AM, Suzanna Lewis <[hidden email]> wrote:
Hi Bob,

We've just had Michael put the file into dropbox and Chris M. is updating the obofoundry.org GAZ from there (so that will be the best site to pull if from).

Chris also noticed some syntax errors which he's removed from the public release. He's sent the list of corrections to Michael and hopefully he'll get them patched up quickly.

It would be absolutely fantastic to have you and others keeping the ball rolling on maintenance! Really great. GAZ already has close to 3/4 million place names, so a lot of work would be lost otherwise.

Sidd, yes GAZ could indeed be maintained the same way as SO. The difference is that right now SO has funding and GAZ is in need of someone to take over from Michael. It's simply a matter of someone minding the store and being there to respond to requests.

GAZ and EnvO originated at the same time (place names in GAZ and habitats/biomes in EnvO). EnvO by and large is now maintained by folks in the meta-genomics community (Oxford and Bremen), and is slowly maturing.

Scott and Karl, format is OBO format. (http://www.geneontology.org/GO.format.obo-1_2.shtml) and there are converters to OWL (not sure how lossy these are). I agree it could be broken up, perhaps by continent like gondwanaland. :-)
 
-S

On Dec 20, 2013, at 2:32 AM, Bob MacCallum <[hidden email]> wrote:

Great thanks Suzanna, yes let's get the ball rolling to open up maintenance.

I hadn't thought about file size limits, but 50MB/100MB is the soft/hard limit at github
https://help.github.com/articles/working-with-large-files
and the 1.51 obo file was 135MB so we have to figure something some workable alternative.

The overall repository size shouldn't be a problem (1GB is the recommended max)




On Thu, Dec 19, 2013 at 11:37 PM, Suzanna Lewis <[hidden email]> wrote:
p.s. I think the only Web presence is under obo (http://obofoundry.org/cgi-bin/detail.cgi?id=gazetteer) or envo (http://environmentontology.org/)

On Dec 19, 2013, at 3:34 PM, Suzanna Lewis <[hidden email]> wrote:

I agree as well. That's the first (and essential) first step.

Michael (copied here) is the primary content person, but he is now officially retired. He's still interested in GAZ, but to be honest its care and content needs to be brought into the modern age. Moving it to github (or equivalent) is essential operationally to keep it Open. Make it so that it's easier for other people to work on it as well.

I know it ran into problems with SVN because of the file size. Chris M. can speak to that.

I'll try and do what I can to help out because it'd be a shame to throw years of effort away. Let me see what I can do.

Plus you're in London? Same time zone as Michael, perhaps arrange a call with him?

-S

On Dec 19, 2013, at 3:03 PM, Bob MacCallum <[hidden email]> wrote:




On Thu, Dec 19, 2013 at 10:30 PM, Suzanna Lewis <[hidden email]> wrote:
Hi Sanjura,

Actually, what would be ideal is that you add what's missing to GAZ. That way the shared community would have these available and it would not require everyone to repeatedly make those inferences individually for themselves alone. The

indeed, but how?  In the past (and also just now) I've never been able to find an up to date web presence for GAZ.  My colleagues have contacts with the GAZ developers and so we've been able to request some changes, but shouldn't the whole thing just be on github so we can contribute in a more transparent way?
 
idea behind all of the ontologies is to work collaboratively to incrementally improve these commonly held resources. Every time someone finds a hole or error and consequently decides to roll their own there can't be further progress. The ontologies are akin to any open source software project - just as GMOD provides a foundation to work upon, same here.

Be nice to see convergence rather than divergence.  
-S 

On Dec 19, 2013, at 12:53 PM, Sanjuro Jogdeo <[hidden email]> wrote:

A good point but looking at the GAZ entries more closely, there are many states/provinces that do not follow the ISO standard that we have used to date.  We have the latitude and longitude associated with each collection and if needed, the community can make region inferences from those.

s


On Thu, Dec 19, 2013 at 10:42 AM, Suzanna Lewis <[hidden email]> wrote:
But you will use the GAZ IDs? (even if you don't load the entire thing).

It would make it so very much easier for the community if you didn't use raw strings or invent y.a. ID system.

-S

On Dec 19, 2013, at 10:31 AM, Sanjuro Jogdeo <[hidden email]> wrote:

Thanks for the suggestions!  GAZ does look like it has the ISO codes we need but also a ton we don't need.  I think I'm going to go with my original plan of just two cvterm ids and nd_geolocationprop values for the country and province names.  We're already using a pre-processing script to validate country and province names so we hopefully won't get invalid names.  All of the rest of the properties will be key value pairs so it might simplify queries as well. 

Thanks so much for the input!  

Sanjuro


On Wed, Dec 18, 2013 at 9:20 AM, Karl O. Pinc <[hidden email]> wrote:
On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:

> When you ask what's the correct way of doing it, you have to think
> about
> end uses for the database - do you need to search on broader
> geographic
> areas*?

An off-hand, un-informed comment:

If I wanted to search geographic areas I'd try to involve
Postgis because that's what it's for.



Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema








------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Bob MacCallum
Hi,

...resurrecting an old thread...

It's vaguely possible that we might be able to fund a few months' developer time - (would have to be Imperial or UK-based telecommute to Imperial I think but not sure) - to get GAZ in a community-editable state in a version control system with a web-based hub (e.g. github/bitbucket).

Does that sound like a good idea to anyone?  If so I can pursue it further.

And if so, do we have the expertise to spec it fully, or does the developer (there is no specific person in mind) need to figure it out also?  (That's a more dangerous proposition.)

cheers,
Bob





On Sat, Dec 21, 2013 at 7:50 PM, Chris Mungall <[hidden email]> wrote:
As Suzi says, the obofoundry site now points to the latest version
http://obofoundry.org/cgi-bin/detail.cgi?id=gazetteer

(I already applied patches to resolve the syntax errors)

We're by passing a version control system at the moment - our continuous integration server grabs the most recent version from Michael's dropbox and creates a release, unless errors are found
(http://build.berkeleybop.org/job/build-gaz/ for those who are interested)

This process also generates an OWL file, using a non-standard obo2owl translation, whereby the "classes" in GAZ are translated to instances, so the OWL version is the 'semantically correct' one (although the OBO version is more convenient for editing).

We're still looking for solutions to modularize GAZ, as this would make it easier both to edit, and to manage in version control. Longer term we may be looking at web-based editing.




On Sat, Dec 21, 2013 at 10:49 AM, Suzanna Lewis <[hidden email]> wrote:
Hi Bob,

We've just had Michael put the file into dropbox and Chris M. is updating the obofoundry.org GAZ from there (so that will be the best site to pull if from).

Chris also noticed some syntax errors which he's removed from the public release. He's sent the list of corrections to Michael and hopefully he'll get them patched up quickly.

It would be absolutely fantastic to have you and others keeping the ball rolling on maintenance! Really great. GAZ already has close to 3/4 million place names, so a lot of work would be lost otherwise.

Sidd, yes GAZ could indeed be maintained the same way as SO. The difference is that right now SO has funding and GAZ is in need of someone to take over from Michael. It's simply a matter of someone minding the store and being there to respond to requests.

GAZ and EnvO originated at the same time (place names in GAZ and habitats/biomes in EnvO). EnvO by and large is now maintained by folks in the meta-genomics community (Oxford and Bremen), and is slowly maturing.

Scott and Karl, format is OBO format. (http://www.geneontology.org/GO.format.obo-1_2.shtml) and there are converters to OWL (not sure how lossy these are). I agree it could be broken up, perhaps by continent like gondwanaland. :-)
 
-S

On Dec 20, 2013, at 2:32 AM, Bob MacCallum <[hidden email]> wrote:

Great thanks Suzanna, yes let's get the ball rolling to open up maintenance.

I hadn't thought about file size limits, but 50MB/100MB is the soft/hard limit at github
https://help.github.com/articles/working-with-large-files
and the 1.51 obo file was 135MB so we have to figure something some workable alternative.

The overall repository size shouldn't be a problem (1GB is the recommended max)




On Thu, Dec 19, 2013 at 11:37 PM, Suzanna Lewis <[hidden email]> wrote:
p.s. I think the only Web presence is under obo (http://obofoundry.org/cgi-bin/detail.cgi?id=gazetteer) or envo (http://environmentontology.org/)

On Dec 19, 2013, at 3:34 PM, Suzanna Lewis <[hidden email]> wrote:

I agree as well. That's the first (and essential) first step.

Michael (copied here) is the primary content person, but he is now officially retired. He's still interested in GAZ, but to be honest its care and content needs to be brought into the modern age. Moving it to github (or equivalent) is essential operationally to keep it Open. Make it so that it's easier for other people to work on it as well.

I know it ran into problems with SVN because of the file size. Chris M. can speak to that.

I'll try and do what I can to help out because it'd be a shame to throw years of effort away. Let me see what I can do.

Plus you're in London? Same time zone as Michael, perhaps arrange a call with him?

-S

On Dec 19, 2013, at 3:03 PM, Bob MacCallum <[hidden email]> wrote:




On Thu, Dec 19, 2013 at 10:30 PM, Suzanna Lewis <[hidden email]> wrote:
Hi Sanjura,

Actually, what would be ideal is that you add what's missing to GAZ. That way the shared community would have these available and it would not require everyone to repeatedly make those inferences individually for themselves alone. The

indeed, but how?  In the past (and also just now) I've never been able to find an up to date web presence for GAZ.  My colleagues have contacts with the GAZ developers and so we've been able to request some changes, but shouldn't the whole thing just be on github so we can contribute in a more transparent way?
 
idea behind all of the ontologies is to work collaboratively to incrementally improve these commonly held resources. Every time someone finds a hole or error and consequently decides to roll their own there can't be further progress. The ontologies are akin to any open source software project - just as GMOD provides a foundation to work upon, same here.

Be nice to see convergence rather than divergence.  
-S 

On Dec 19, 2013, at 12:53 PM, Sanjuro Jogdeo <[hidden email]> wrote:

A good point but looking at the GAZ entries more closely, there are many states/provinces that do not follow the ISO standard that we have used to date.  We have the latitude and longitude associated with each collection and if needed, the community can make region inferences from those.

s


On Thu, Dec 19, 2013 at 10:42 AM, Suzanna Lewis <[hidden email]> wrote:
But you will use the GAZ IDs? (even if you don't load the entire thing).

It would make it so very much easier for the community if you didn't use raw strings or invent y.a. ID system.

-S

On Dec 19, 2013, at 10:31 AM, Sanjuro Jogdeo <[hidden email]> wrote:

Thanks for the suggestions!  GAZ does look like it has the ISO codes we need but also a ton we don't need.  I think I'm going to go with my original plan of just two cvterm ids and nd_geolocationprop values for the country and province names.  We're already using a pre-processing script to validate country and province names so we hopefully won't get invalid names.  All of the rest of the properties will be key value pairs so it might simplify queries as well. 

Thanks so much for the input!  

Sanjuro


On Wed, Dec 18, 2013 at 9:20 AM, Karl O. Pinc <[hidden email]> wrote:
On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:

> When you ask what's the correct way of doing it, you have to think
> about
> end uses for the database - do you need to search on broader
> geographic
> areas*?

An off-hand, un-informed comment:

If I wanted to search geographic areas I'd try to involve
Postgis because that's what it's for.



Karl <[hidden email]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema




------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema









------------------------------------------------------------------------------

_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: cv relationships

Chris Mungall-5
Hi Bob,

Currently the gaz.obo is almost 4 times the size limit imposed by github
(50m).

The solution we have now seems to work (although Michael, I think you
may need to rehare your dropbox).

I would still like to pursue the modularization strategy. The challenge
here is to do it in such a way that works in the confines of oboedit,
which has limited multi-ontology capability. This means minimizing edges
between modules, which may turn out to be a straightforward graph
clustering problem. But the end result of this analysis would have to be
thoroughly tested and a solution proposed for how to edit inter-module
edges.

On 4 Apr 2014, at 2:19, Bob MacCallum wrote:

> Hi,
>
> ...resurrecting an old thread...
>
> It's vaguely possible that we might be able to fund a few months'
> developer
> time - (would have to be Imperial or UK-based telecommute to Imperial
> I
> think but not sure) - to get GAZ in a community-editable state in a
> version
> control system with a web-based hub (e.g. github/bitbucket).
>
> Does that sound like a good idea to anyone?  If so I can pursue it
> further.
>
> And if so, do we have the expertise to spec it fully, or does the
> developer
> (there is no specific person in mind) need to figure it out also?  
> (That's
> a more dangerous proposition.)
>
> cheers,
> Bob
>
>
>
>
>
> On Sat, Dec 21, 2013 at 7:50 PM, Chris Mungall <[hidden email]>
> wrote:
>
>> As Suzi says, the obofoundry site now points to the latest version
>> http://obofoundry.org/cgi-bin/detail.cgi?id=gazetteer
>>
>> (I already applied patches to resolve the syntax errors)
>>
>> We're by passing a version control system at the moment - our
>> continuous
>> integration server grabs the most recent version from Michael's
>> dropbox and
>> creates a release, unless errors are found
>> (http://build.berkeleybop.org/job/build-gaz/ for those who are
>> interested)
>>
>> This process also generates an OWL file, using a non-standard obo2owl
>> translation, whereby the "classes" in GAZ are translated to
>> instances, so
>> the OWL version is the 'semantically correct' one (although the OBO
>> version
>> is more convenient for editing).
>>
>> We're still looking for solutions to modularize GAZ, as this would
>> make it
>> easier both to edit, and to manage in version control. Longer term we
>> may
>> be looking at web-based editing.
>>
>>
>>
>>
>> On Sat, Dec 21, 2013 at 10:49 AM, Suzanna Lewis
>> <[hidden email]>wrote:
>>
>>> Hi Bob,
>>>
>>> We've just had Michael put the file into dropbox and Chris M. is
>>> updating
>>> the obofoundry.org GAZ from there (so that will be the best site to
>>> pull
>>> if from).
>>>
>>> Chris also noticed some syntax errors which he's removed from the
>>> public
>>> release. He's sent the list of corrections to Michael and hopefully
>>> he'll
>>> get them patched up quickly.
>>>
>>> It would be absolutely fantastic to have you and others keeping the
>>> ball
>>> rolling on maintenance! Really great. GAZ already has close to 3/4
>>> million
>>> place names, so a lot of work would be lost otherwise.
>>>
>>> Sidd, yes GAZ could indeed be maintained the same way as SO. The
>>> difference is that right now SO has funding and GAZ is in need of
>>> someone
>>> to take over from Michael. It's simply a matter of someone minding
>>> the
>>> store and being there to respond to requests.
>>>
>>> GAZ and EnvO originated at the same time (place names in GAZ and
>>> habitats/biomes in EnvO). EnvO by and large is now maintained by
>>> folks in
>>> the meta-genomics community (Oxford and Bremen), and is slowly
>>> maturing.
>>>
>>> Scott and Karl, format is OBO format. (
>>> http://www.geneontology.org/GO.format.obo-1_2.shtml) and there are
>>> converters to OWL (not sure how lossy these are). I agree it could
>>> be
>>> broken up, perhaps by continent like gondwanaland. :-)
>>>
>>> -S
>>>
>>> On Dec 20, 2013, at 2:32 AM, Bob MacCallum
>>> <[hidden email]>
>>> wrote:
>>>
>>> Great thanks Suzanna, yes let's get the ball rolling to open up
>>> maintenance.
>>>
>>> I hadn't thought about file size limits, but 50MB/100MB is the
>>> soft/hard
>>> limit at github
>>> https://help.github.com/articles/working-with-large-files
>>> and the 1.51 obo file was 135MB so we have to figure something some
>>> workable alternative.
>>>
>>> The overall repository size shouldn't be a problem (1GB is the
>>> recommended max)
>>>
>>>
>>>
>>>
>>> On Thu, Dec 19, 2013 at 11:37 PM, Suzanna Lewis
>>> <[hidden email]>wrote:
>>>
>>>> p.s. I think the only Web presence is under obo (
>>>> http://obofoundry.org/cgi-bin/detail.cgi?id=gazetteer) or envo (
>>>> http://environmentontology.org/)
>>>>
>>>> On Dec 19, 2013, at 3:34 PM, Suzanna Lewis <[hidden email]>
>>>> wrote:
>>>>
>>>> I agree as well. That's the first (and essential) first step.
>>>>
>>>> Michael (copied here) is the primary content person, but he is now
>>>> officially retired. He's still interested in GAZ, but to be honest
>>>> its care
>>>> and content needs to be brought into the modern age. Moving it to
>>>> github
>>>> (or equivalent) is essential operationally to keep it Open. Make it
>>>> so that
>>>> it's easier for other people to work on it as well.
>>>>
>>>> I know it ran into problems with SVN because of the file size.
>>>> Chris M.
>>>> can speak to that.
>>>>
>>>> I'll try and do what I can to help out because it'd be a shame to
>>>> throw
>>>> years of effort away. Let me see what I can do.
>>>>
>>>> Plus you're in London? Same time zone as Michael, perhaps arrange a
>>>> call
>>>> with him?
>>>>
>>>> -S
>>>>
>>>> On Dec 19, 2013, at 3:03 PM, Bob MacCallum
>>>> <[hidden email]>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Dec 19, 2013 at 10:30 PM, Suzanna Lewis
>>>> <[hidden email]>wrote:
>>>>
>>>>> Hi Sanjura,
>>>>>
>>>>> Actually, what would be ideal is that you add what's missing to
>>>>> GAZ.
>>>>> That way the shared community would have these available and it
>>>>> would not
>>>>> require everyone to repeatedly make those inferences individually
>>>>> for
>>>>> themselves alone. The
>>>>>
>>>>
>>>> indeed, but how?  In the past (and also just now) I've never been
>>>> able
>>>> to find an up to date web presence for GAZ.  My colleagues have
>>>> contacts
>>>> with the GAZ developers and so we've been able to request some
>>>> changes, but
>>>> shouldn't the whole thing just be on github so we can contribute in
>>>> a more
>>>> transparent way?
>>>>
>>>>
>>>>> idea behind all of the ontologies is to work collaboratively to
>>>>> incrementally improve these commonly held resources. Every time
>>>>> someone
>>>>> finds a hole or error and consequently decides to roll their own
>>>>> there
>>>>> can't be further progress. The ontologies are akin to any open
>>>>> source
>>>>> software project - just as GMOD provides a foundation to work
>>>>> upon, same
>>>>> here.
>>>>>
>>>>> Be nice to see convergence rather than divergence.
>>>>> -S
>>>>>
>>>>> On Dec 19, 2013, at 12:53 PM, Sanjuro Jogdeo
>>>>> <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> A good point but looking at the GAZ entries more closely, there
>>>>> are
>>>>> many states/provinces that do not follow the ISO standard that we
>>>>> have used
>>>>> to date.  We have the latitude and longitude associated with each
>>>>> collection and if needed, the community can make region inferences
>>>>> from
>>>>> those.
>>>>>
>>>>> s
>>>>>
>>>>>
>>>>> On Thu, Dec 19, 2013 at 10:42 AM, Suzanna Lewis
>>>>> <[hidden email]>wrote:
>>>>>
>>>>>> But you will use the GAZ IDs? (even if you don't load the entire
>>>>>> thing).
>>>>>>
>>>>>> It would make it so very much easier for the community if you
>>>>>> didn't
>>>>>> use raw strings or invent y.a. ID system.
>>>>>>
>>>>>> -S
>>>>>>
>>>>>> On Dec 19, 2013, at 10:31 AM, Sanjuro Jogdeo
>>>>>> <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>> Thanks for the suggestions!  GAZ does look like it has the ISO
>>>>>> codes
>>>>>> we need but also a ton we don't need.  I think I'm going to go
>>>>>> with my
>>>>>> original plan of just two cvterm ids and nd_geolocationprop
>>>>>> values for the
>>>>>> country and province names.  We're already using a pre-processing
>>>>>> script to
>>>>>> validate country and province names so we hopefully won't get
>>>>>> invalid
>>>>>> names.  All of the rest of the properties will be key value pairs
>>>>>> so it
>>>>>> might simplify queries as well.
>>>>>>
>>>>>> Thanks so much for the input!
>>>>>>
>>>>>> Sanjuro
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 18, 2013 at 9:20 AM, Karl O. Pinc <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> On 12/18/2013 06:24:18 AM, Bob MacCallum wrote:
>>>>>>>
>>>>>>>> When you ask what's the correct way of doing it, you have to
>>>>>>>> think
>>>>>>>> about
>>>>>>>> end uses for the database - do you need to search on broader
>>>>>>>> geographic
>>>>>>>> areas*?
>>>>>>>
>>>>>>> An off-hand, un-informed comment:
>>>>>>>
>>>>>>> If I wanted to search geographic areas I'd try to involve
>>>>>>> Postgis because that's what it's for.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Karl <[hidden email]>
>>>>>>> Free Software:  "You don't pay back, you pay forward."
>>>>>>>               -- Robert A. Heinlein
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Rapidly troubleshoot problems before they affect your business.
>>>>>>> Most
>>>>>>> IT
>>>>>>> organizations don't have a clear picture of how application
>>>>>>> performance
>>>>>>> affects their revenue. With AppDynamics, you get 100% visibility
>>>>>>> into
>>>>>>> your
>>>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>>>>>>> AppDynamics Pro!
>>>>>>>
>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>>>>>>> _______________________________________________
>>>>>>> Gmod-schema mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Rapidly troubleshoot problems before they affect your business.
>>>>>> Most
>>>>>> IT
>>>>>> organizations don't have a clear picture of how application
>>>>>> performance
>>>>>> affects their revenue. With AppDynamics, you get 100% visibility
>>>>>> into
>>>>>> your
>>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>>>>>> AppDynamics Pro!
>>>>>>
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
>>>>>> Gmod-schema mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Rapidly troubleshoot problems before they affect your business.
>>>>> Most IT
>>>>> organizations don't have a clear picture of how application
>>>>> performance
>>>>> affects their revenue. With AppDynamics, you get 100% visibility
>>>>> into
>>>>> your
>>>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>>>>> AppDynamics Pro!
>>>>>
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Gmod-schema mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>

------------------------------------------------------------------------------
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
12