|
From: Jim C. <jr...@an...> - 2002-10-30 01:42:35
|
>Personally I remain somewhat uneasy with having different schemas for the >different purposes since I would like it to be possible for software to >validate all of our data mappings and I am not sure that we could easily do >it between two or more arbitrary schemas. yes - it would be nice to be able to specify the entire biodiversity data enterprise (or at least the biological collections component of it) in only one place... >My hope (based on the combination of the DiGIR meetings and the ABCD >sessions) is that any future version of Darwin Core will in fact model >documents which are valid under the ABCD Schema (a small subset of the total >set of fields, probably corresponding to what most people will in fact be >able to populate within the schema). I think that this should be possible >and will in fact allow us in practice to maintain a single schema without >any philosophical issues about how to perform correct mappings between the >schemas. Conceptually, will we not end up with a Darwin core that is simply a flattened subset of ABCD? If that is the case, I think it would make a lot of sense to handle or the definitions and constraints in a single comprehensive schema. >The problem is that even Darwin Core will >include repeating subelements (e.g. for collector or higher taxon). This >will mean that we need to understand how to model these within DiGIR >queries. yes - but to start with a flat DC with no repeating elements would still be incredibly useful/powerful as a query framework that we could live with that for the time being if it makes implementation any easier. However, we would definitely want to deliver and receive repeating elements in the result set (determination histories, numeric/time ranges, etc.) >The bottom line here is that I think our level of agreement in Brazil was in >part because BioCASE needed to be able to separate the query and result >schemas whereas I assumed that we would ultimately be able to combine both >as different subsets of the same schema. I quite agree. The DC elements could be nailed down rather quickly so that all the mucking around that is going to take place for the wider ABCD will not hold up progress for the Species Analyst type queries that are going on at the moment. >We ignored larger questions about >what the DiGIR protocol may or may not be able to achieve because the >specific case which interests us first can probably work without answering >them. yes - but, in the Australian context at least, we are going to want delivery of repeating values for certain data elements as soon as possible. > Speaking both from my role in GBIF and as a software architect I >would like to see DiGIR become a common transport and query protocol for use >in any subject domain in which we want to exchange data. For that reason I >would like to resolve these more abstract issues before we go too far. yes - DIGIR/ABCD should do it all... nothing short of complete global biodiversity domination... tomorrow, the world... jim ~ Jim Croft ~ jr...@an... ~ 02-62465500 ~ www.anbg.gov.au/jrc/ ~ |