big-devel Mailing List for Biodiversity Information Group

Brought to you by: anbgibis, naib

big-devel — List for discussion of BIG development.

You can subscribe to this list here.

2001	_Jan	_Feb	_Mar	_Apr	_May	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov	_Dec (2)
2002	_Jan	_Feb	_Mar	_Apr	_May	_Jun (4)	_Jul	_Aug (3)	_Sep	_Oct (81)	_Nov (21)	_Dec
2009	_Jan	_Feb	_Mar	_Apr	_May	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov (2)	_Dec

Flat | Threaded

1 2 3 .. 5 > >> (Page 1 of 5)

Re: [Big-devel] Test message to BIG-DEVEL [SEC=UNCLASSIFIED]

From: Chapman, A. <Ale...@de...> - 2009-11-02 06:47:22

Hi Paul,

Well - yes - I expect there are a few of us who read any messages here, but it is true there is little activity here.
Check out the HISCOM wiki http://hiscom.chah.org.au/wiki/Main_Page for a better overview of Australian plant bioinformatics resources.

Alex
____
Alex R. Chapman                    Email: al...@de...
FloraBase Manager              http://florabase.dec.wa.gov.au<http://florabase.dec.wa.gov.au/>
Research Scientist           Voice/Fax: +61 8 9334 0513 /0515
WA Herbarium   -   Department of Environment and Conservation
Locked Bag 104 Bentley Delivery Centre Western Australia 6983


________________________________
From: Paul Murray [mailto:pm...@an...]
Sent: Monday, 2 November 2009 8:53 AM
To: big...@li...
Subject: [Big-devel] Test message to BIG-DEVEL [SEC=UNCLASSIFIED]

I'm not sure how active this list is, or if anyone reads it, so I am posting this messge.


______________
"In theory, there is no difference between theory and practice. But in practise, there often is."

Paul Murray
pm...@an...<mailto:pm...@an...>; Pau...@en...<mailto:Pau...@en...>; pm...@bi...<mailto:pm...@bi...>; pau...@us...<mailto:pau...@us...>
http://twitter.com/PaulMurrayCbr
http://paulmurray.users.sourceforge.net/
http://paulmurray.id.au
[61] 0404164112






------
If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments.

Please consider the environment before printing this email.
------

This email, together with any attachments, is intended for the
addressee only. It may contain confidential or privileged information.
If you are not the intended recipient of this email, please notify
the sender, delete the email and attachments from your system and
destroy any copies you may have taken of the email and its attachments.
Duplication or further distribution by hardcopy, by electronic means
or verbally is not permitted without permission.

[Big-devel] Test message to BIG-DEVEL [SEC=UNCLASSIFIED]

From: Paul M. <pm...@an...> - 2009-11-02 01:02:43

I'm not sure how active this list is, or if anyone reads it, so I am  
posting this messge.


______________
"In theory, there is no difference between theory and practice. But in  
practise, there often is."

Paul Murray
pm...@an...; Pau...@en...;  
pm...@bi...; pau...@us...
http://twitter.com/PaulMurrayCbr
http://paulmurray.users.sourceforge.net/
http://paulmurray.id.au
[61] 0404164112







------
If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments. 



Please consider the environment before printing this email.

------

[Big-devel] Problem Mapserver error message

From: Ben R. <be...@ca...> - 2002-11-21 05:43:45

I've put together an in-house development site for testing the AVH, but
have come up against an error message from MapServer:

"loadSymbol(): GD library error."

The MapServer home page lists this as an error with the use of GIF files
in the *.sym file, but I can't find any reference to GIF files in our
avh/symbols/symbols.sym file.

Is there any other reason I'd be getting this?  Does GD need to be
installed?  If so where should I expect to find it?

Cheers,
Ben

--
Ben Richardson
Western Australian Herbarium, CALM
<be...@ca...> <http://florabase.calm.wa.gov.au>
<tel://61.8.9334.0511> <fax://61.8.9334.0515>

RE: [Big-devel] Dithering of geocode

From: Ben R. <be...@ca...> - 2002-11-20 01:26:08

> -----Original Message-----
> From: big...@li...
> [mailto:big...@li...]On Behalf Of Jim Croft


> He assured me the NSW one is ok so it is, now linked; I will
> be relinking CANB shortly, MEL looks ok unless I hear
> otherwise, I will relink that one too.  Ben - are you happy
> with PERTH?

PERTH is (mostly) happy - see below.

> For the geocode at least, is this something that could be done at the
> portal rather than (or as well as) at the provider side?

PERTH is intending to dither the geocodes for rare/threatened taxa it
knows about.

The issue of a Consensus Census raises its ugly head, though.  PERTH has
no way of knowing the conservation status of plants outside of WA!

The problem with dithering at the portal end is that for a time, the
data is on the wire in full precision.  This is an unacceptable risk.

Cheers,
Ben

[Big-devel] Dithering of geocode

From: Jim C. <jr...@an...> - 2002-11-20 01:03:28

Greg has just been checking our AVH implementation to ensure that we are 
dithering our public records appropriately.

You will notice on the CHAH AVH site we removed all the links to the 
portals until we  were happy that they we not delivering inappropriate data 
to the public.  Tim asked us to put them back because they are needed for 
promotional demonstration purposes.

He assured me the NSW one is ok so it is, now linked; I will be relinking 
CANB shortly, MEL looks ok unless I hear otherwise, I will relink that one 
too.  Ben - are you happy with PERTH?

Anyway, Greg and I have been talking about where the dithering takes 
place.  At the moment, each institution undertakes to dither the geocode on 
the provider side, strip out or dumb down the locality, etc. in response to 
a request, and when you look at the data there is not much in the way on 
consistency in how this is done.

For the geocode at least, is this something that could be done at the 
portal rather than (or as well as) at the provider side?  That is, could we 
ensure that each AVH  node ensures that the geocode is dumbed down to the 
nearest 5 minutes (or whatever), regardless of what precision it comes in 
at?   This would ensure a minimum tolerance, but individual institution 
could still deliver coarser information if they so wished according to 
their local policy.

jim

ps - does anyone have a current and official copy of the HISPID fields for 
public data consumption agreed by CHAH following the AD CHAH 
meeting?   This is a foundation document and sort of our equivalent to our 
version of the Darwin Core - it should be on the source forge site and as 
part of the distribution documentation somewhere...


~ Jim Croft ~ jr...@an... ~ 02-62465500 ~ www.anbg.gov.au/jrc/ ~

[Big-devel] avh code

From: Peter N. <Pet...@rb...> - 2002-11-15 06:00:41

I've put the avh2-1-1 code up on the private cvs server:

http://cvs.rbg.vic.gov.au/big/

I suggest that any modifications to the main bits of code go here (i.e.
avh.cgi, avhxml.cgi, AVH:Tools.pm etc).

Probably the best way to attack it would be to put in the bug / feature
request into sourceforge and then assign it to someone (e.g. yourself)
work on it if you can and commit the changes. Anyone can put in a
feature request.

We can also host the layers and templates here, so anyone who has them
can load them or tell me where I can get them and I'll do it.

Cheers,

Peter
--------------------------------------------------------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed.

If you have received this email in error please notify the
originator of the message. This footer also confirms that this
email message has been scanned for the presence of computer viruses.

Any views expressed in this message are those of the individual
sender, except where the sender specifies and, with authority,
states them to be the views of Royal Botanic Gardens Board, Victoria.

[Big-devel] Fwd: AVH software implementation

From: Jim C. <jr...@an...> - 2002-11-14 05:25:59

The email note below was sent off list to a number of hiscom members who 
had been fiddling with implementation and installation of the AVH software 
and is basically a call to arms (and panic) in relation to getting the AVH 
into a launchable state.

Greg has brought the AVH distribution code to the top of his pile and I 
hope others are doing likewise.

we are now taking to conversation, and hopefully subsequent applications 
development, across to the BIG Developers list on 
big...@li...

I have copied this email to hiscom because I notice a numbers are not on 
the BIG Developers email list.

Hope everyone can join the party...

jim


>Date: Thu, 14 Nov 2002 08:00:37 +1100
>To: gh...@an..., Pet...@rb..., be...@ca..., 
>ken...@rb..., Co...@la...
>From: Jim Croft <jr...@an...>
>Subject: AVH software implementation
>Cc: mur...@ea..., sd...@an..., jud...@cs..., 
>tim...@rb...
>
>ok guys - apart from tarting up html pages, Siobhan, Murray and I have got 
>as far as we can get...
>
>    http://www.chah.gov.ay/avh
>
>all the pointers to mapper nodes go to a watch this space stub until 
>people can assure us they are happy with the locality details that are 
>being released to the public.
>
>The AVH Trust is about to meet and it would be nice to have at least one 
>site linked in that can deliver real data at a suitable public resolution.
>
>What is required now is some serious effort on the mapper so we can link 
>to some active nodes that deliver the same query form and the same information.
>
>How are we going to get this damn thing to happen?  Quickly?
>
>Peter has rewritten one of the executables to do more of what we want to 
>do and placed it sourceforge - have others installed it?   Can it become 
>part of the distribution?   Does it need any discussion and tweaking of 
>configuration to achieve the output we want?
>
>Can someone attack some of the other files?
>
>We have circulated a mockup of what we want the avh.cgi query screen to 
>look like (an extra row to cover infraspecies, additional classes of GIS 
>coverages, links to help files etc.   We can not fudge this with external 
>HTML - it has to be built into the scripts.  Who is going to do 
>this?  Like right now?
>
>Ken:  you were going to follow up some of the global GIS coverages I sent 
>the URL for from Brazil.  How did you go?  People really like the 
>rendition of the relief and bathymetry on these layers - they are much 
>more aesthetically pleasing than the ones we have been using.  Can we cut 
>these into the application and make these part of the distribution?
>
>Murray and Siobhan can not get any further with the explanation pages for 
>the map output until we finalize what it is going to look like.  This too 
>is part of the AVH scripts and configuration files  who is going to get at 
>this?
>
>The links to other resources page needs a bit of work to add some 
>additional resources and links to explanatory stuff?  Is that a separate 
>module that one of us can work on?
>
>Is the separation of the public query/result and the internal query/result 
>clear enough?  Are we the herbaria getting everything and are the public 
>getting an acceptable subset?  Is there a leakage of private stuff to the 
>public arena that is likely to freak anyone out?
>
>We really do need an avh example of a bounding box query (range of 
>lat/long) that returns a list of species or specimens (perhaps the latter 
>for internal use only to start with).
>
>I have a list of things that needs doing that is so long that it makes me 
>ill to think about it...  what is stressing me out is that nearly all of 
>them now are part of the avh code and beyond my control.  I can not do or 
>change anything.  I am relying on you guys to help me out here.  I am 
>talking serious desperation...
>
>I am having this initial conversation off line to see if we can get things 
>moving quickly... it needs to be the highest priority on all our desks at 
>the moment... we are starting to lose serious credibility here at a time 
>when we are expecting the Trust to go hunting for significant money for us 
>and when we are trying to come up with a product we can share with OZCAM 
>and others and get us out of this KE IP bind.  Once we get moving (i.e. 
>after this email) I would like to move discussion back into the wider 
>forum - what do you think Ben?  the hiscom or the big-devel list, being 
>conscious of the fact that a number of hiscom participants are not members 
>of the latter?
>
>jim
>
>~ Jim Croft ~ jr...@an... ~ 02-62465500 ~ www.anbg.gov.au/jrc/ ~

~ Jim Croft ~ jr...@an... ~ 02-62465500 ~ www.anbg.gov.au/jrc/ ~

[Big-devel] Today's checkins

From: Ben R. <be...@ca...> - 2002-11-11 04:38:15

Firstly, sorry about the mega-spam checkin emails on big-cvs.  We need
to find a tool for notifications that won't bother putting the file
contents in the email, I think.

==========
Metaschema
==========

I've dropped in Jim's suggestions for the metaschema, which have cleaned
up the "element" element quite a bit.

Jim: Yes, these make sense.  We didn't need to document some of the
things we were previously, because we'll be able to find those things
out by using XSLT to look at the schema facets/enumerations/type for
each element.

I still reckon we'll have little need for
hispidDictionary/element/shortName, but at least it is optional.

I also changed the "hispidReferences" element to bring it into line with
Jim's changes in "hispidDictionary".

=============
AVH web files
=============

Jim sent me a large number of files that were put together by ABRS
designers, such as the help files and a newer presentation of the AVH
screen etc.

I've placed these in big/avh/portalhtml under two subdirectories,
"static" (for the pages that will go "as is" into the AVH server's
htdocs directory), and "template" (for the files that will need further
editing for use by the AVH software as template files).

The designers can now hack away directly on this stuff.

Cheers,
Ben

--
Ben Richardson
Western Australian Herbarium, CALM
<be...@ca...> <http://florabase.calm.wa.gov.au>
<tel://61.8.9334.0511> <fax://61.8.9334.0515>

RE: Namespace URLs (was RE: [Big-devel] big bad mother schema)

From: Jim C. <jr...@an...> - 2002-11-07 11:15:37

>I think you're missing my point, I'm not intending to be secretive.
>Just the reverse - I'm referring to a namespace URL, which must be as
>available as possible to those applications that need it.

so am I...   I think we are actually saying the same thing here...

>This is distinct from the page(s) that we access from our (current
>generation) web browsers to browse HTML pages about the HISPID standard.

yes...

>It may be that in time, the current web browsers evolve the capability
>to browse schemas in an elegant user interface.  In that case we might
>have the ability to use the namespace URL as both the target for XML
>applications and the interested user after information on HISPID.

yes - and in the mean time we have a permanent target XML namespace
for hispid versions 5, then 6, then 7...  AND, as discussed previously, a 
verbose,
fully commented  version to be rendered in human form by XSLT if necessary...

I think we are on the same page here...

jim

~ Jim Croft ~ jr...@an... ~ 02-62465500 ~ www.anbg.gov.au/jrc/ ~

[Big-devel] Namespaces for fun

From: Ben R. <be...@ca...> - 2002-11-07 01:48:18

Mozilla's XML User interface Language (XUL), has a namespace URL of

http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul

If you've ever watched Ghostbusters, this might be familiar...

Mozilla uses this XML schema to define the user interface, as well as
allow other applications to be created on the Mozilla codebase.

Cheers,
Ben

--
Ben Richardson
Western Australian Herbarium, CALM
<be...@ca...> <http://florabase.calm.wa.gov.au>
<tel://61.8.9334.0511> <fax://61.8.9334.0515>

RE: Namespace URLs (was RE: [Big-devel] big bad mother schema)

From: Ben R. <be...@ca...> - 2002-11-07 01:19:57

> -----Original Message-----
> From: big...@li...
> [mailto:big...@li...]On Behalf Of Jim Croft

> >The URLs I'm referring to are not for general use.  They are
> intended as
> >the source for a particular version of a particular data
> standard set in
> >XML Schema.
>
> well they might as well be.  Then they can serve the function of the
> namespace definition.  The is no point in being secretive
> about these things...

Jim

I think you're missing my point, I'm not intending to be secretive.
Just the reverse - I'm referring to a namespace URL, which must be as
available as possible to those applications that need it.

This is distinct from the page(s) that we access from our (current
generation) web browsers to browse HTML pages about the HISPID standard.

It may be that in time, the current web browsers evolve the capability
to browse schemas in an elegant user interface.  In that case we might
have the ability to use the namespace URL as both the target for XML
applications and the interested user after information on HISPID.

Cheers,
Ben

Re: Namespace URLs (was RE: [Big-devel] big bad mother schema)

From: Jim C. <jr...@an...> - 2002-11-06 12:38:12

>The URLs I'm referring to are not for general use.  They are intended as
>the source for a particular version of a particular data standard set in
>XML Schema.

well they might as well be.  Then they can serve the function of the 
namespace definition.  The is no point in being secretive about these things...

>In the case of XML Schema, the URL we use needs to point to a *.xsd
>document.  As this document eventually becomes the reference for a lot
>of applications (such as XML Spy), they come to expect to find a
>particular version of a schema at that location.
>The URL must be unique to that schema version.

yes...

>If we change this URL, we potentially break any applications making use
>of the standard (because of incompatibility between versions, for
>example).  This tends to annoy application developers somewhat.

yes - once it is in place, that is where and how it has to stay... this 
might be a problem with souurceforge, but not with chah...

>Thus, we must be careful to provide a unique but guessable schema
>location URL for each version of HISPID that we choose to develop in XML
>Schema (or whatever comes next..).

machines do not guess... all it has to be is unambiguous...  obviously 
simpler is better though...

jim


~ Jim Croft ~ jr...@an... ~ 02-62465500 ~ www.anbg.gov.au/jrc/ ~

Namespace URLs (was RE: [Big-devel] big bad mother schema)

From: Ben R. <be...@ca...> - 2002-11-05 03:29:11

> -----Original Message-----
> From: big...@li...
> [mailto:big...@li...]On Behalf Of Jim Croft


> >While it would be good to have permanent repository
> destination URLs for
> >each version, I think it would be more effective to have a simpler
> >permanent generic URL for the latest HISPID info; ie.
> >         http://www.chah.gov.au/hispid/index.html
>
> I have often wondered why people do not do this with name
> spaces - just
> have a one size fits all that gets updated...  (w3c always
> have an arcane
> url with dates and versions)...
>
> this probably only works if you keep adding stuff and do not
> take anything
> out...  I agree using the version/release should be sufficient...


The URLs I'm referring to are not for general use.  They are intended as
the source for a particular version of a particular data standard set in
XML Schema.

In the case of XML Schema, the URL we use needs to point to a *.xsd
document.  As this document eventually becomes the reference for a lot
of applications (such as XML Spy), they come to expect to find a
particular version of a schema at that location.

The URL must be unique to that schema version.

If we change this URL, we potentially break any applications making use
of the standard (because of incompatibility between versions, for
example).  This tends to annoy application developers somewhat.

Thus, we must be careful to provide a unique but guessable schema
location URL for each version of HISPID that we choose to develop in XML
Schema (or whatever comes next..).

Cheers,
Ben

Re: [Big-devel] big bad mother schema (was RE: RE: appinfo stuff)

From: Greg W. <gh...@an...> - 2002-11-05 02:51:37

> >While it would be good to have permanent repository destination URLs for
> >each version, I think it would be more effective to have a simpler
> >permanent generic URL for the latest HISPID info; ie.
> >         http://www.chah.gov.au/hispid/index.html
> 
> I have often wondered why people do not do this with name spaces - just 
> have a one size fits all that gets updated...  (w3c always have an arcane 
> url with dates and versions)...
> 

Not wanting to break all existing documents using your namespace,
perhaps.

greg
-- 

 

Australian                  I             GPO Box 1777 Canberra 2601
National           GREG WHITBREAD             voice: +61 2 62509 482
Botanic  Integrated Botanic Information System  fax: +61 2 62509 599
Gardens    ...............  S ....... I.T. happens.. gh...@an...

Re: [Big-devel] big bad mother schema (was RE: RE: appinfo stuff)

From: Jim C. <jr...@an...> - 2002-11-05 02:14:40

>While it would be good to have permanent repository destination URLs for
>each version, I think it would be more effective to have a simpler
>permanent generic URL for the latest HISPID info; ie.
>         http://www.chah.gov.au/hispid/index.html

I have often wondered why people do not do this with name spaces - just 
have a one size fits all that gets updated...  (w3c always have an arcane 
url with dates and versions)...

this probably only works if you keep adding stuff and do not take anything 
out...  I agree using the version/release should be sufficient...

jim

~ Jim Croft ~ jr...@an... ~ 02-62465500 ~ www.anbg.gov.au/jrc/ ~

Re: [Big-devel] big bad mother schema (was RE: RE: appinfo stuff)

From: Chapman, A. <al...@ca...> - 2002-11-05 01:35:41

Jim, Ben,

While it would be good to have permanent repository destination URLs for
each version, I think it would be more effective to have a simpler
permanent generic URL for the latest HISPID info; ie.=20

	http://www.chah.gov.au/hispid/index.html

This page would summarize the current state of play with HISPID, clearly
indicating the latest official version and also listing the release
history with appropriate links to each versions URL (as already
suggested, although personally I would prefer simply the version in the
URL, not the year, perhaps
http://www.chah.gov.au/hispid/hispid5/index.html ).

A.

> >Is there an area on chah.gov.au that we could set aside for
> > publishing
> >our official schemas?  How about this for HISPID5:
> >http://www.chah.gov.au/2002/hispid5
> >we could then use other similar URLs for newer releases:
> >http://www.chah.gov.au/2004/hispid6
>
> this would work... do we need the year?

>Probably not (it doesn't really matter, I'm just trying to think
ahead),
>so long as we continue the broad version numbering.  Otherwise we could
>use:
>
>a) http://www.chah.gov.au/2002/hispid
>
>b) http://www.chah.gov.au/2004/hispid


____
Alex R. Chapman                   Email: al...@ca...
Research Scientist           Voice/Fax: +61 8 9334 0513 /0515
WA Herbarium - Department of Conservation and Land Management
Locked Bag 104 Bentley Delivery Centre Western Australia 6983=20

> -----Original Message-----
> From: Richardson, Ben=20
> Sent: Monday, 4 November 2002 2:16 PM
> To: 'Big-Devel (E-mail)'
> Subject: RE: Fwd: Re: [Big-devel] big bad mother schema (was RE: RE:
> appinfo stuff)
>=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: big...@li...
> > [mailto:big...@li...]On Behalf Of Jim Croft
>=20
> > >In order to enable our namespace properly, we really need=20
> a permanent
> > >URL on the chah.gov.au web site to use for HISPID schemas along the
> > >lines of the W3C for its schemas.
> >
> > I had not thought about this...  yes we need a stable place for the
> > namespace...
> > I guess CHAH is the most appropriate place for this
> > activity...  I do not
> > think DIGIR and ABCD have thought this far ahead...
> >
> > >Is there an area on chah.gov.au that we could set aside for
> > publishing
> > >our official schemas?  How about this for HISPID5:
> > >http://www.chah.gov.au/2002/hispid5
> > >we could then use other similar URLs for newer releases:
> > >http://www.chah.gov.au/2004/hispid6
> >
> > this would work... do we need the year?
>=20
> Probably not (it doesn't really matter, I'm just trying to=20
> think ahead),
> so long as we continue the broad version numbering. =20
> Otherwise we could
> use:
>=20
> a) http://www.chah.gov.au/2002/hispid
>=20
> b) http://www.chah.gov.au/2004/hispid
>=20
> The point being that each of these would ALWAYS point to the expected
> version, and implicit in this is that forever afterwards,=20
> this URL would
> provide an answer.
>=20
> I guess my initial examples will be easiest to implement given the
> current file name, "hispid5.xsd".
>=20
> Also, on that web site, you might need to separate the schema=20
> documents
> a bit more from other stuff hosted there:
>=20
> a2) http://www.chah.gov.au/HISPID/hispid5
>=20
> or whatever..
>=20
> future versions could then be
>=20
> b2) http://www.chah.gov.au/HISPID/hispid51
>=20
> etc.
>=20
> Given all the possible needs of the staff on the chah.gov.au=20
> web site, I
> favour example a2, above.
>=20
> Cheers,
> Ben
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: ApacheCon, November 18-21 in
> Las Vegas (supported by COMDEX), the only Apache event to be
> fully supported by the ASF. http://www.apachecon.com
> _______________________________________________
> Big-devel mailing list
> Big...@li...
> https://lists.sourceforge.net/lists/listinfo/big-devel
>=20