November 2005 - tdwg-tag - lists.tdwg.org

Re: Two Scenarios
by Roderic Page 25 Nov '05

25 Nov '05

These relationships would be specified in the metadata attached to the GUIDs, not the GUIDs themselves (they are simply unique identifiers). For example, if we think of you tax number/Social Security Number/National Insurance Number (insert whatever identifier your government attaches to you here), then you could have two GUIDs such as JE 5679434A and JH 5679434B The metadata for JE 5679434A could contain a statement that the individuals are related, e.g. something like <rdf:Description rdf:about="JE 5679434A"> <isMarriedTo rdf:resource ="JH 5679434B" /> </rdf:Description> In other words, the person identifed by "JE 5679434A" is married to the person identified by "JH 5679434B". One can develop ontologies that specify these relationships, and enable us to deduce other facts. For example, if X is married to Y, then Y is married to X, but if Z is a child of Y, Y is the parent of Z, and so on. What is nice is that you wouldn't have to explicitly state that Y is the parent of Z in the metadata Y, it can be inferred from the relationship Z is a child of Y. I use RDF here because these are the kind of things it handles nicely. All (!) you'd need is a consistent vocabulary to describe the relationships. RDF already has some basic ones ("sameAs", "subPropertyOf", etc.). In the examples you provide, I guess you'd want "part of", "extracted from", "hosted by", "parent of", "mother of", etc. Does this help? Regards Rod On 25 Nov 2005, at 11:18, Arthur Chapman wrote: > Below I have placed two scenarios that show some of the > cross-discipline problems I believe we face with GUIDs. They don't > provide the answers, alas! > > It would appear to me that each of these separate entities need a > GUID; but that each needs to show some relationship (nearly a > genealogy or pedigree line) - child of (i.e. derived from); brother of > (duplicate collection); sister of (wet collection); part of (genetic > study) etc. Can these be built into a GUID? > > If we just look at the simplest problem, where a herbarium makes a > collection and sends out duplicates to other herbaria. More often > than not, the duplicates are distributed prior to receiving a > catalogue number in the originating ionstitution. We can only thus > identify duplicates using collector name and number, but these are not > always unique, and not all collectors use numbers. - We can't use the > lat/long coordinates as these are often put on after distribution and > are often different (one collection I looked at in 5 different > herbaria was given 4 different lat/longs). The resolution of many of > these duplicates will need to be a human problem - possibly helped by > parsing routines similar those being developed for location > information in the BioGeomancer project, and possibly some artificial > intelligence (to sort out collector's names used in different ways, > etc. - initials first/surname first, etc.). > > I wish I could supply the answers! > > These scenarios don't show up all that well in text, I have also > attached a word document. > > --------------------- > PLANT > 1. Collector Makes collection > a. Provides collector number (not always Unique) <Fred 123> > i. Submits collection to Herbarium > 1. Herbarium supplies collection number <Index Herbarium-CANB12345> > 2. and a name <TCS-123454> > a. Herbarium distributes collections to other herbaria > i. New herbaria supply collection numbers <IH-NY65432; > IH-MO34562; IH-K98765> > ii. New herbarium creates wet collection in alcohol > <IH-NY-wet-65432> > b. Herbarium takes tissue samples and cultivates and propagates > in living collection > i. Living collections supplies a number <BotGard-ANBG99-24-12-18> > 1. Living collection makes a new collection for herbarium > <IH-CANB35556> > c. University researcher takes pollen sample and carries out > analysis. > i. Stores microscope slide of pollen grains <ANUxxxx342567587> > 1. carries out genetic study > a. sends collection to GenBank <Genbank 456783> > ii. Submits seeds to Seed Bank > 1. Seed bank supplies a number <CSIRO-Euc34547> > a. Seed bank supplies seed to China where it is cultivated. > i. China takes sample for chemical assay <XXXX3435646763> > 1. Develops drug and applies for patent <USA Pat xxxxxxxx> > ------------------- > > ZOO ANIMAL > 2. Collector catches two animals > a. Probably doesnt give a number > b. Sells animals to two different zoos > i. Zoo A documents and gives animal a number <ZOOA-xxxxx22323> > 1. Animal was pregnant and gives birth to 2 young (parent unknown) > 2. Animals given numbers <ZOOA-xxxxx22323-1; ZOOA-xxxxx22323-2> > a. Young (1) sold to Zoo B > i. Zoo B gives a number <ZOOB-yyy34562> > ii. Young (1) develops a parasite > 1. Parasite sent to Lab 1 <LAB1-2222342> > a. Lab identifies parasite and sends specimen to Museum > <Museum-FL12322> > b. Young (2) dies > i. Specimen sent to Museum <Museum XY2222234> > 1. Tissue sample taken and stored <Museum XY2222234-a> > 2. Skin sample sent to different museum <Museum BT4563721> > ii. Zoo B documents and gives animal number <ZOOB-yyy12345> > 1. Zoo B crosses ZOOB-yyy12345 with ZOOB-yyy34562 > a. Offspring born and given numbers <ZOOB-yyy673221; > ZOOB-yyy673222> > i. Animal ZOOB-yyy673221 sold to Zoo C > 1. Zoo C supplies number <ZOOC-22245> needs to link pedigree. > ii. Animal ZOOB-yyy673222 etc. > \etc. > > Hope this helps and just doesn't confuse the issue even more. > > Arthur Chapman > Toowoomba, Australia > > ------------------------------------------------------------------------ ---------------------------------------- Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page(a)bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names at http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species at http://ispecies.org

1 0

Re: Two Scenarios
by Arthur Chapman 24 Nov '05

24 Nov '05

Rod This is a neat solution and may well work. I like it! It is somewhat akin to the "Relation" element in Dublin Core but which has generally not been implemented with a controlled vocabulary as was recommended at the Canberra meeting of Dublin Core in about 1996 or 1997. It was implemented in the Australian Government Locator Service (AGLS) as Australian Standard AS5044 with a controlled vocabulary. The vocabulary is not what we would need, but gives a parallel example isVersionOf hasVersion isReplacedBy replaces isRequiredBy requires isPartOf isReferencedBy isFormatOf hasFormat isBasisFor isBasedOn http://www.naa.gov.au/recordkeeping/gov_online/agls/AGLS_reference_descript… Cheers Arthur >>>From Roderic Page <r.page(a)BIO.GLA.AC.UK> on 25 Nov 2005: > These relationships would be specified in the metadata attached to the > GUIDs, not the GUIDs themselves (they are simply unique identifiers). > > For example, if we think of you tax number/Social Security > Number/National Insurance Number (insert whatever identifier your > government attaches to you here), then you could have two GUIDs such as > > JE 5679434A > > and > > JH 5679434B > > The metadata for JE 5679434A could contain a statement that the > individuals are related, e.g. something like > > <rdf:Description rdf:about="JE 5679434A"> > <isMarriedTo rdf:resource ="JH 5679434B" /> > </rdf:Description> > > In other words, the person identifed by "JE 5679434A" is married to the > > > person identified by "JH 5679434B". > > One can develop ontologies that specify these relationships, and enable > > > us to deduce other facts. For example, if X is married to Y, then Y is > married to X, but if Z is a child of Y, Y is the parent of Z, and so > on. What is nice is that you wouldn't have to explicitly state that Y > is the parent of Z in the metadata Y, it can be inferred from the > relationship Z is a child of Y. > > I use RDF here because these are the kind of things it handles nicely. > All (!) you'd need is a consistent vocabulary to describe the > relationships. RDF already has some basic ones ("sameAs", > "subPropertyOf", etc.). In the examples you provide, I guess you'd want > > > "part of", "extracted from", "hosted by", "parent of", "mother of", > etc. > > Does this help? > > Regards > > Rod > > > > > > > On 25 Nov 2005, at 11:18, Arthur Chapman wrote: > > > Below I have placed two scenarios that show some of the > > cross-discipline problems I believe we face with GUIDs. They don't > > provide the answers, alas! > > > > It would appear to me that each of these separate entities need a > > GUID; but that each needs to show some relationship (nearly a > > genealogy or pedigree line) - child of (i.e. derived from); brother > of> > > (duplicate collection); sister of (wet collection); part of (genetic > > study) etc. Can these be built into a GUID? > > > > If we just look at the simplest problem, where a herbarium makes a > > collection and sends out duplicates to other herbaria. More often > > than not, the duplicates are distributed prior to receiving a > > catalogue number in the originating ionstitution. We can only thus > > identify duplicates using collector name and number, but these are > not> > > always unique, and not all collectors use numbers. - We can't use the > > > > lat/long coordinates as these are often put on after distribution and > > > > are often different (one collection I looked at in 5 different > > herbaria was given 4 different lat/longs). The resolution of many of > > these duplicates will need to be a human problem - possibly helped by > > > > parsing routines similar those being developed for location > > information in the BioGeomancer project, and possibly some artificial > > > > intelligence (to sort out collector's names used in different ways, > > etc. - initials first/surname first, etc.). > > > > I wish I could supply the answers! > > > > These scenarios don't show up all that well in text, I have also > > attached a word document. > > > > --------------------- > > PLANT > > 1. Collector Makes collection > > a. Provides collector number (not always Unique) <Fred 123> > > i. Submits collection to Herbarium > > 1. Herbarium supplies collection number <Index > Herbarium-CANB12345> > > > 2. and a name <TCS-123454> > > a. Herbarium distributes collections to other herbaria > > i. New herbaria supply collection numbers <IH-NY65432; > > IH-MO34562; IH-K98765> === message truncated ==

1 0

Two Scenarios
by Arthur Chapman 24 Nov '05

24 Nov '05

Below I have placed two scenarios that show some of the cross-discipline problems I believe we face with GUIDs. They don't provide the answers, alas! It would appear to me that each of these separate entities need a GUID; but that each needs to show some relationship (nearly a genealogy or pedigree line) - child of (i.e. derived from); brother of (duplicate collection); sister of (wet collection); part of (genetic study) etc. Can these be built into a GUID? If we just look at the simplest problem, where a herbarium makes a collection and sends out duplicates to other herbaria. More often than not, the duplicates are distributed prior to receiving a catalogue number in the originating ionstitution. We can only thus identify duplicates using collector name and number, but these are not always unique, and not all collectors use numbers. - We can't use the lat/long coordinates as these are often put on after distribution and are often different (one collection I looked at in 5 different herbaria was given 4 different lat/longs). The resolution of many of these duplicates will need to be a human problem - possibly helped by parsing routines similar those being developed for location information in the BioGeomancer project, and possibly some artificial intelligence (to sort out collector's names used in different ways, etc. - initials first/surname first, etc.). I wish I could supply the answers! These scenarios don't show up all that well in text, I have also attached a word document. --------------------- PLANT 1. Collector Makes collection a. Provides collector number (not always Unique) <Fred 123> i. Submits collection to Herbarium 1. Herbarium supplies collection number <Index Herbarium-CANB12345> 2. and a name <TCS-123454> a. Herbarium distributes collections to other herbaria i. New herbaria supply collection numbers <IH-NY65432; IH-MO34562; IH-K98765> ii. New herbarium creates wet collection in alcohol <IH-NY-wet-65432> b. Herbarium takes tissue samples and cultivates and propagates in living collection i. Living collections supplies a number <BotGard-ANBG99-24-12-18> 1. Living collection makes a new collection for herbarium <IH-CANB35556> c. University researcher takes pollen sample and carries out analysis. i. Stores microscope slide of pollen grains <ANUxxxx342567587> 1. carries out genetic study a. sends collection to GenBank <Genbank 456783> ii. Submits seeds to Seed Bank 1. Seed bank supplies a number <CSIRO-Euc34547> a. Seed bank supplies seed to China where it is cultivated. i. China takes sample for chemical assay <XXXX3435646763> 1. Develops drug and applies for patent <USA Pat xxxxxxxx> ------------------- ZOO ANIMAL 2. Collector catches two animals a. Probably doesnt give a number b. Sells animals to two different zoos i. Zoo A documents and gives animal a number <ZOOA-xxxxx22323> 1. Animal was pregnant and gives birth to 2 young (parent unknown) 2. Animals given numbers <ZOOA-xxxxx22323-1; ZOOA-xxxxx22323-2> a. Young (1) sold to Zoo B i. Zoo B gives a number <ZOOB-yyy34562> ii. Young (1) develops a parasite 1. Parasite sent to Lab 1 <LAB1-2222342> a. Lab identifies parasite and sends specimen to Museum <Museum-FL12322> b. Young (2) dies i. Specimen sent to Museum <Museum XY2222234> 1. Tissue sample taken and stored <Museum XY2222234-a> 2. Skin sample sent to different museum <Museum BT4563721> ii. Zoo B documents and gives animal number <ZOOB-yyy12345> 1. Zoo B crosses ZOOB-yyy12345 with ZOOB-yyy34562 a. Offspring born and given numbers <ZOOB-yyy673221; ZOOB-yyy673222> i. Animal ZOOB-yyy673221 sold to Zoo C 1. Zoo C supplies number <ZOOC-22245> needs to link pedigree. ii. Animal ZOOB-yyy673222 etc. \etc. Hope this helps and just doesn't confuse the issue even more. Arthur Chapman Toowoomba, Australia

1 0

[tdwg-tapir] Conversation with people from the Geoserver software.
by Javier de la Torre 23 Nov '05

23 Nov '05

Hi all, I do not know if I should post this here but I felt this may be of interest of everybody working in the protocol. I was doing some questions about the configuration of Geoserver to provide a WMS and WFS service that I am creating, I think you all know about it. The mapping configuration between the database and the GML for the WFS service inside Geoserver is quite limited, but there are some people working on ways to improve it. I introduced a little bit what we are doing and they answer all this... I hope it is of your interest... if anybody want to join the discussion go and subscribe to geoserver-devel(a)lists.sourceforge.net Javi. Begin forwarded message: > From: Chris Holmes <cholmes(a)openplans.org> > Date: 23 de noviembre de 2005 20:55:29 GMT+01:00 > To: Javier de la Torre <jatorre(a)gmail.com> > Cc: geoserver-devel(a)lists.sourceforge.net, rob(a)socialchange.net.au > Subject: Re: [Geoserver-devel] Re: [Geoserver-users] schema.xml file > > Quoting Javier de la Torre <jatorre(a)gmail.com>: > >> Hi Chris, >> >> Interesting discussion! >> >>>> In our mapping language (we call it >>>> CMF, concept mapping file) comparable to schema.xml file we allow >>>> complicate mappings with filters, conditional mappings and things >>>> like that. I suppose is pretty much the same thing you are >> thinking. >>> Interesting. It could be interesting to try to sync up the work >> we're >>> both doing. I don't like everyone reinventing the wheel for >> mapping >>> files, but I don't know of anyone else really doing them. Perhaps >> we >>> could try to use the same file format between our projects. The >>> 'filters' that we make use of our primarily OGC Filters - their >>> representation of a where statement. >>> >>> Short (rough) overview here: >>> http://udig.refractions.net/confluence/display/GOWS/Querying+data >>> +using+%27Filter%27 >>> and full spec is here: >>> http://portal.opengeospatial.org/files/?artifact_id=8340 (pdf) >> >> >> Well, Ok, let's go in parts. >> What we are working is in an HTTP-XML protocol to allow dynamic >> queries to heterogeneous databases and get results in XML compliant >> to whatever XML schema they have mapped their databases... (puff this >> may not be the best description of it...). In our community (TDWG, >> Taxonomic Database Working Group, a very little OGC like >> standardization group) there are two protocols for doing that, Digir >> and bioCASe, and now we are merging them into a new one called TAPIR. >> There will be two implementations of this protocol. The protocol, >> very much like the WFS protocol, is still under discussion in a wiki >> page http://ww3.bgbm.org/protocolwiki/FrontPage. >> >> Actually the WFS protocol was reviewed when creating this new >> protocol because it was considered a possible solution to our >> problems. If you take a look at our capability operation is very >> likely to WFS one, and the filtering in a query is also very similar >> to the one you pointed me (because we also get inspired by it!). >> >> For this protocol we are creating there will be two reference >> implementations, pywrapper in python, and Digir 2 in Java and RDF >> based. > Interesting. Looking at the schemas it actually looks a bit closer to > catalogue than WFS: > http://portal.opengeospatial.org/files/?artifact_id=5929&version=2 > Unfortunately it's not as solid of a spec, and there aren't any good > open source reference implementations. > > I wonder if it'd be possible to get some of your specs to line up more > with OGC ones, and vice-versa. Because it'd be really nice to be able > to share code and implementations. Like if it was possible to do just > a few extensions to WFS for your needs, then you could just contribute > to GeoServer, and the core would be stronger for all. And people > could > use the same parsing tools on both GML and your schemas, and the same > clients to communicate back and forth. I'm not sure how practical any > of this actually is, but I _hate_ reduplication of work, and it just > seems at the core we're doing a lot of the same stuff. > > The Catalogue spec has a good bit on a common query language, if you > were to support that, and the same XML filters for example, then we > could share code with GeoTools. > >>> >>> >>> We already had an implementation of them in GeoTools, since we're >> OGC >>> focused, so they made logical sense to do the mappings (correct me >> if >>> I'm wrong here Gabriel). A nice thing about them is that we >> already >>> have most of the code written to 'unpack' them, that is if the back >>> end >>> data format can perform the filter, then we turn it into the SQL >> (or >>> whatever query language it might use). So we should be able to get >>> good performance out of the mappings, since where possible it's >> passed >>> to the backend. But the nice thing is that we _can_ do it on >>> anything, >>> since there's Java code for it all, so Shapefile supports all >> filters >>> as well. >>> >> >> Uhm... I do not understand this totally... >> You mean that implementing a more intelligent mapping will let you >> create dynamically SQL statements that you can use for filtering >> based on the query filter? I feel I may be mixing everything... >> >> In our case we describe the database structure and we map the >> database to the different schemas that we want to share the data in. >> When someone do a query the wrapper read this configuration file and >> figure out the where clause to filter the data in the SQL statement. >> Then depending on the xml schema that is requested as a response it >> selects the necessary information from the database to populate an >> XML instance of this XML schema. > Yeah, we do a similar thing, I guess the point of difference is that > we're not always dealing with databases, so we're not always able to > turn the filter into SQL, so we do so in Java code. > >> >> Well, in reality it is a little bit more complicate to give the >> mapping of the database-schema the necessary information to create >> correct xml documents... Unfortunately an XML schema can validate >> many different XML documents that looks completely different... >> >>> >>>> I am working also >>>> for a European project called Synthesys and I was planning to get >> in >>>> contact with the INSPIRE project in the near soon when I get more >> OGC >>>> knowledge :) >>> Excellent. If you want some contacts I know at least one good one. >>> >> >> Yes! that would be great... I feel is a shame I am not in contact >> with them when I am aiming at providing GIS services in a european >> level... > Ok, I'll let you know. > > And the thing I don't quite understand, how does the geographic stuff > relate to the work you're doing on the spec? Like are you planning on > geographic stuff as part of it? Or would you set up a database with > both a TAPIR interface and a WFS interface? > >> >>>> >>>> What you are planning to do with complex mappings looks quite >> similar >>>> to the problem that we are trying to solve too. As I described we >>>> have a wrapper tool to make possible to connect heterogenous >>>> databases to a network where we can query them using a standard >>>> protocol (TAPIR and BioCASe before), the results from the >> providers >>>> come in XML following a certain "conceptual schema" (what you call >>>> application schema). Maybe we should have a talk and I will show >> you >>>> how are we doing things and you may get some ideas... >>> Yeah, that could be good. I don't know how far in to things you >> are, >>> but note that a WFS doesn't _have_ to do geometric objects. Like >> it >>> could theoretically not return any GML at all, just XML. I don't >> know >>> if that's the route to go, but it might weirdly be worthwhile to >> just >>> sync your effort up with GeoTools/GeoServer, since we would both >>> benefit from more users and use cases. But yeah, at the very least >> it >>> sounds like we're working on very similar problems, and can learn >> what >>> works and what doesn't, even if it doesn't make sense to share at >> the >>> coding level. >>> >> >> >> As I said before when we were discussing our protocol we took a look >> at available protocols and one of those was WFS. I was not resposible >> for that and I do not know the exact reason why it was discard (it >> should be in the protocol review uhmm). But... is it possible with >> WFS to do paging? I mean... in our case someone retrieve ten >> "features" and then want to retrieve the next 10... > No WFS does not currently do paging, but I actually don't think > that not > currently meeting all your capabilities is a good enough reason to > reject a spec. Because it wouldn't be very hard to add a 'paging' > capability to a WFS. I mean, make a schema that extends WFS a bit, > for > paging, make a reference implementation, and make it your official > thing, and could even try to get it rolled back into the OGC specs. I > quote I quite like about standards is this: > > 'This tinkering with the [standardized] protocol, however, is not an > empirical fact showing the limits of standardization in practice. > We do > not point at these instances in order to demonstrate the ‘resistance’ > of actors to domination. Rather, we argue that the ongoing > subordination and (re)articulation of the [standardized] protocol to > meet the primary goals of the actors involved is a sine qua non for > the > functioning of the [standardized] protocol in the first place.' > Timmermans and Berg (1997: p. 291.) > > The point is you _should_ take a standard and improve it to your > needs, > the point of standards is a basis to meet further needs. And if you > start with a standard, it's much, much easier to build upon lots of > other work that's gone before. Like if it's super similar to WFS, > then > there could easily be both open source and commercial implementations > of your spec made. > > I think Catalogue actually does have a concept of paging. It's > concepts > could probably be applied to WFS. At the GeoTools level Jody is doing > some work now for a Random Access API, which could make paging quite > easy. > > But it looks like you're already too far along to really switch paths, > and I'm not sure if the OGC specs would hold up to all your needs, > even > expanding them where appropriate. > >> >> >>>> At the end seems everybody is working on the same problem, the >>>> mapping of relational databases to XML schemas... >>> Yeah, there's a lot out there, and a lot of different approaches, >>> and it >>> feels silly to roll so much of your own. But many are lacking in >>> different ways. We're hoping with our approach to eventually be >> able >>> to sync up with other more generic things. We looked into using >>> Hibernate to do the object-relational mapping, but Rob needed to be >>> able to control the SQL select statements, so you could derive your >>> mapping from the results of a select statement, which hibernate >> just >>> doesn't let you. And we wrote a straight SAX producer to stream >> out >>> GML, since at the time there were no good, fast object -> XML >>> producers >>> that allowed you real flexibility, since we have to deal with >>> arbitrary >>> Features, of arbitrary complexity, can't define the schema >> beforehand. >>> There are solutions now, and I think our next generation >>> parser/producer makes of JAXB. But yeah, working with Geographic >>> Information we hit a lot of the big problems early, since the >> datasets >>> so quickly get huge. >>> >> >> Yes, in our case this is an issue... we have to be able to page >> trough datasets because even the fastest wrapper in the world will >> not be able to retrieve 1 million features full of properties at >> once... that's why we have paging. >> One could thing we are trying to implement, for example, is that the >> user is able to send the structure, the "complex_type", in an XML >> schema fragment specifying the result formats he want the data to be >> responded. There is a two step-mapping going here but I do not want >> to get long now... > That's really interesting, I could see that being very useful from a > WFS/GML perspective as well: > > In OGC there's this concept of a Feature Portrayl Service, that > takes a > WFS and an SLD, which is an XML language to specify how to 'style' a > map, what the image should look like, and returns an image. It's > similar to a WMS, but sort of fully virtual, since nothing really sits > on the server. > > It'd be very interesting to see such a thing for full GML, it would > take > a WFS and a Mapping file as arguments, and perform the mapping, > returning the result as GML, a sort of virtual WFS. So if someone > else > put their data up as WFS, but didn't bother to get it into a well > known > schema, then you could just do it yourself. > > When we get the Complex Feature stuff sorted out in GeoServer this > type > of thing shouldn't be all that hard. We already support WFS as a > DataSource (in addition to a number of databases and file formats), > and > then we'd just need to define a mapping file. > > It seems like it'd be _really_ nice to have a common spec for the > 'mapping file' we're talking about, how you apply filters and whatnot > to go from one format/schema to another. Rob, any thoughts about > that? > We're just kind of rolling our own this round, right? It could be a > cool win to have clients be able to choose the schema they want to > view > data in, and just connect to a WFS supplying their chosen mapping. > >> >> The project web page of one of this implementation is at http:// >> ww3.bgbm.org/tapir and if you want to see a data provider in action >> you can go to http://ww3.bgbm.org/tapirwrapper/ > Looks cool. > > best regards, > > Chris > > >> >> Best regards, >> >> Javier. >> >> >>> best regards, >>> >>> Chris >>> >>> >>>> >>>> Javier. >>>> >>>> >>>> >>>> On 23/11/2005, at 8:23, Chris Holmes wrote: >>>> >>>>> Actually, Javier, you're getting into the bleeding edge of >>>> GeoServer, >>>>> and you actually understand how WFS and GML _should_ work >>>> perfectly. >>>>> Rob has been pushing these types of things for awhile, and just >>>>> recently managed to get a lot of the ideas in GeoServer as >> working >>>>> code >>>>> with Gabriel. The schema.xml files were not about actually >> mapping >>>>> your GML to different types, they were just kind of surface level >>>> ways >>>>> of renaming things. The problem of actually getting names to map >>>> back >>>>> and forth, to perform filters on them, and more, is much more >>>> complex. >>>>> >>>>> The problem is the code is on a branch, like Gabriel just >> announced >>>> it >>>>> last week, and there will still be bugs, and there's lots of >>>>> documentation to write. But we would love to have you as a user >>>>> testing it out. Indeed your intended schema is pretty simple >>>> compared >>>>> to the complexity of what we're hoping to support. >>>>> >>>>> See the 'proto-documentation' (really just a place holder) here: >>>>> >>>> http://docs.codehaus.org/display/GEOSDOC/Complex+Feature >>>> +Documentation >>>>> >>>>> As for MySQL, if you're using the MySQL module you need to have >>>> your >>>>> points stored as Geometries, see: >>>>> http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions-in- >>>>> mysql.html >>>>> (it's available in 4.1 as well). As for improvements from 4.1 to >>>> 5.0, >>>>> I haven't tried out 5.0, but looking at the docs there appears to >>>> be >>>>> nothing new, the support overall is pretty poor, I'd recommend >>>>> upgrading to PostGIS asap. >>>>> >>>>> If you really want to define your MySQL table as just x,y >>>> coordinates, >>>>> Rob made a Geometryless module that will work, but we don't >>>> currently >>>>> include it with GeoServer. I believe Gabriel upgraded it though >> in >>>>> his >>>>> latest work. >>>>> >>>>> best regards, >>>>> >>>>> Chris >>>>> >>>>> >>>>> Quoting Justin Deoliveira <jdeolive(a)unknown-road.com>: >>>>> >>>>>> Hi Javier, >>>>>> >>>>>> So what you need is the wfs to serve up gml that conforms to >> your >>>>>> application schema. After you add your data store and feature >> type >>>> to >>>>>> geoserver (via the config gui), your feature type will contain >>>>>> attributes with the default types. You can customize the types >>>> with >>>>>> the >>>>>> feature type editor. There are some docs on how to do this here. >>>>>> >>>>>> http://docs.codehaus.org/display/GEOSDOC/FeatureType+Config >>>>>> >>>>>> Note the part about changing the type of an attribute to an xml >>>>>> fragment. >>>>>> >>>>>> Unfortunatley I dont know much about mysql, and even less about >>>> its >>>>>> spatial extension. However I am sure someone else will be able >> to >>>>>> help >>>>>> with that. And questions about mysql could probably be best >>>> answered >>>>>> on >>>>>> the geotools devel and user lists. I would try repositing those >>>>>> questions there. >>>>>> >>>>>> If you have any more questions dont hesitate to ask. >>>>>> >>>>>> Justin >>>>>> >>>>>> >>>>>> Javier de la Torre wrote: >>>>>>> Hi Justin, >>>>>>> >>>>>>> Thanks for your answer. >>>>>>> Some background. I am using MySQL right now as a DataStore (but >>>>>> also >>>>>>> planning to go for PostGIS). In my database I have a table >> where >>>> I >>>>>> have >>>>>>> records of specimens (plants) with information like their name, >>>>>> who >>>>>>> identified them, when they were collected, etc. Also I have in >>>> the >>>>>> same >>>>>>> table coordinates of the location where these plants where >>>>>> collected. >>>>>>> >>>>>>> My idea is to create a WFS service to provide the points where >>>> the >>>>>>> specimens where collected together with the other information. >> We >>>>>> have >>>>>>> some kind of standards about how all this information must be >>>>>>> described. The idea is to create a GML application schema where >>>> we >>>>>>> describe the specimens using our own "concepts" (like >>>> CatalogNumber >>>>>> and >>>>>>> things like that) and the location of the specimen using a >>>>>>> gml:PointPropertyType. >>>>>>> >>>>>>> If I let Geoserver create automatically the schema for me I get >>>>>>> something like this: >>>>>>> >>>>>>> ---------- >>>>>>> <xs:complexType name = "specimens_Type" > >>>>>>> <xs:complexContent> >>>>>>> <xs:extension base = "gml:AbstractFeatureType" > >>>>>>> <xs:sequence> >>>>>>> <xs:element type = "xs:string" minOccurs = "1" name = >>>>>> "SpecimenGUID" >>>>>>> nillable = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "xs:string" minOccurs = "0" name = >>>>>> "ProjectTitle" >>>>>>> nillable = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "xs:string" minOccurs = "0" name = >>>> "BiotopeText" >>>>>>> nillable = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "xs:dateTime" minOccurs = "0" name = >>>>>>> "CollectingISODate" nillable = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "xs:string" minOccurs = "0" name = >>>>>> "LocalityText" >>>>>>> nillable = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "xs:string" minOccurs = "0" name = >>>> "CountryName" >>>>>>> nillable = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "xs:string" minOccurs = "0" name = "Notes" >>>>>> nillable >>>>>>> = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "xs:int" minOccurs = "0" name = >>>>>> "AltitudeLowerValue" >>>>>>> nillable = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "xs:string" minOccurs = "0" name = >>>> "coordinates" >>>>>>> nillable = "true" maxOccurs = "1" /> >>>>>>> </xs:sequence> >>>>>>> </xs:extension> >>>>>>> </xs:complexContent> >>>>>>> </xs:complexType> >>>>>>> ------------- >>>>>>> >>>>>>> But I would prefer to get something like: >>>>>>> >>>>>>> ----------- >>>>>>> <xs:complexType name = "specimens_Type" > >>>>>>> <xs:complexContent> >>>>>>> <xs:extension base = "gml:AbstractFeatureType" > >>>>>>> <xs:sequence> >>>>>>> <xs:element type = "my_ns:GUID" minOccurs = "1" name = >>>>>> "SpecimenGUID" >>>>>>> nillable = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "my_ns:ProjectTitle" minOccurs = "0" name = >>>>>>> "ProjectTitle" nillable = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "my_ns: BiotopeText" minOccurs = "0" name = >>>>>>> "BiotopeText" nillable = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "my_ns:dateTime" minOccurs = "0" name = >>>>>>> "CollectingISODate" nillable = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "my_ns:string" minOccurs = "0" name = >>>>>> "LocalityText" >>>>>>> nillable = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "my_ns:string" minOccurs = "0" name = >>>>>> "CountryName" >>>>>>> nillable = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "my_ns:string" minOccurs = "0" name = >> "Notes" >>>>>>> nillable = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "my_ns:int" minOccurs = "0" name = >>>>>>> "AltitudeLowerValue" nillable = "true" maxOccurs = "1" /> >>>>>>> <xs:element type = "gml:PointPropertyType" minOccurs = "0" name >> = >>>>>>> "coordinates" nillable = "true" maxOccurs = "1" /> >>>>>>> </xs:sequence> >>>>>>> </xs:extension> >>>>>>> </xs:complexContent> >>>>>>> </xs:complexType> >>>>>>> ---------------- >>>>>>> >>>>>>> And by the way... how do I have to define the coordinates in my >>>>>> MySQL >>>>>>> table so that Geoserver understand them as Points in gml? In >> the >>>>>> case >>>>>>> of PostGIS is this done automatically? >>>>>>> >>>>>>> A final question... I do not find any documentation about the >>>>>> spatial >>>>>>> capabilities of MySQL 5, do you know if there is any >> improvement >>>>>> from >>>>>>> what it was available already in 4.1? >>>>>>> >>>>>>> I am new to OGC standards so i am still a little bit confused >> on >>>>>> how to >>>>>>> create this GML application schemas so sorry if I am asking no- >>>>>> sense... >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> Javier. >>>>>>> >>>>>>> >>>>>>> On 22/11/2005, at 20:29, Justin Deoliveira wrote: >>>>>>> >>>>>>>> Hi Javier, >>>>>>>> >>>>>>>> I suspect that the GML writer ignores the information that you >>>>>> have >>>>>>>> supplied in the schema.xml file, and generates the gml from >> the >>>>>>>> actual features / feature types themselves. >>>>>>>> >>>>>>>> Since the DescribeFeatureType logic takes place in GeoServer >>>>>> itself, >>>>>>>> it can be smart and delegate to the schema.xml file. However >>>> the >>>>>> GML >>>>>>>> writing logic takes place in the geotools library, and it has >>>> no >>>>>>>> notion of this file. >>>>>>>> >>>>>>>> Can you tell us a bit more about how you are trying to >> customize >>>>>> your >>>>>>>> schema. Perhaps there is another way around this problem. >>>>>>>> >>>>>>>> Justin >>>>>>>> >>>>>>>> Javier de la Torre wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> I am starting to play with Geoserver and until now I have to >>>> say >>>>>> I >>>>>>>>> am impressed by how easy is to install and configure, >>>>>>>>> congratulations!! >>>>>>>>> But when trying to edit a schema.xml file to adapt the output >>>> of >>>>>> a >>>>>>>>> WFS service I get into problems. In the documentation it >> says: >>>>>>>>> "The last file is not always present, it is the schema.xml >>>> file. >>>>>>>>> This is a tricky file - if present it is used directly for a >>>>>>>>> DescribeFeatureType response, but configuration information >> is >>>>>> also >>>>>>>>> read from it. If it is absent then the DescribeFeatureType >>>>>> response >>>>>>>>> is automatically generated by GeoServer with the default >>>>>>>>> AttributeTypes of the DataStore (such as the columns of the >>>>>> table)." >>>>>>>>> But if I edit manually this file Geoserver does not take care >>>> of >>>>>> it >>>>>>>>> for producing the GML of the features, but it does for the >>>>>>>>> DescribeFeatureType.... >>>>>>>>> And the Graphical interface automatically overwrite to the >>>>>> default >>>>>>>>> one... >>>>>>>>> Do you know what is going on? >>>>>>>>> Thanks in advance. >>>>>>>>> Javier. >>>>>>>>> ------------------------------------------------------- >>>>>>>>> This SF.Net email is sponsored by the JBoss Inc. Get >> Certified >>>>>> Today >>>>>>>>> Register for a JBoss Training Course. Free Certification >> Exam >>>>>>>>> for All Training Attendees Through End of 2005. For more info >>>>>> visit: >>>>>>>>> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >>>>>>>>> _______________________________________________ >>>>>>>>> Geoserver-users mailing list >>>>>>>>> Geoserver-users(a)lists.sourceforge.net >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Justin Deoliveira >>>>>>>> The Open Planning Project >>>>>>>> http://topp.openplans.org >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Justin Deoliveira >>>>>> The Open Planning Project >>>>>> http://topp.openplans.org >>>>>> >>>>>> >>>>>> ------------------------------------------------------- >>>>>> This SF.Net email is sponsored by the JBoss Inc. Get Certified >>>> Today >>>>>> Register for a JBoss Training Course. Free Certification Exam >>>>>> for All Training Attendees Through End of 2005. For more info >>>> visit: >>>>>> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >>>>>> _______________________________________________ >>>>>> Geoserver-users mailing list >>>>>> Geoserver-users(a)lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------- >>>>> This mail sent through IMP: https://webmail.limegroup.com/ >>>> >>> >>> >>> >>> >>> ---------------------------------------------------------- >>> This mail sent through IMP: https://webmail.limegroup.com/ >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through >> log files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD >> SPLUNK! >> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >> _______________________________________________ >> Geoserver-devel mailing list >> Geoserver-devel(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> > > > > > ---------------------------------------------------------- > This mail sent through IMP: https://webmail.limegroup.com/

1 0

Re: RDF/architecture/ontology - migration
by Patricia Mergen 23 Nov '05

23 Nov '05

Dear Roger In this mail you were asking the question : "How much should the GUID debate assume that we are using current XML Schema based standards and how much should it assume a move to an RDF style approach - or doesn't it matter?" In some way I would answer yes it does matter in the sens that if possible a GUID system should be used that is independant of the fact that curently XML Schema are used and that they are likely to move to RDF. In several years who knows which other system will be use to express standards (with a acronym not yet invented ...). My question is to the subscribers of our list is. Do you have suggestions for a GUID system that would be as much as possible independant from the "method" used to express the standards and exchange information ? I believe we have to think here on the very long term so that hopefully our sucessors in 200 years can still find back our "legacy data" more easely than the way we have to deal currently we legacy data ;) Pat Roger Hyam <roger(a)TDWG.ORG> wrote: This is carrying on from Steve's comments under the "Taxon debate synthesis?" thread. I started a new thread as it seemed to be getting a little deep and no longer fitting the title. Steve's comments are hitting the nail right on the head. From the conversations and thoughts I am having about architecture of TDWG standards all roads are leading to RDF - which is annoying because it makes writing balanced documents that compare the alternatives difficult :) Steve outlined one of the most promising paths forward for TDWG standards. Taking this route is not a matter of just saying "lets do it all in RDF" there would be a long way to go if we went this way - but at least we would be doing things the same way the rest of the semantic web world and that means there are tools and people out there to help. The one point Steve didn't stress is that RDF is the "bees knees" for data handshaking - i.e. combining data from different domains. This means that the extensibility and version problems that are our main hurdles as the moment will tend to go away. But have no fear there will be other problems to replace them. I am comfortable talking about GUIDs in terms of moving towards representing TDWG data in RDF. It certainly makes more sense of the GUID discussions to me. But... What we need to bear in mind is that there is a great deal of knowledge captured in XML Schema within the TDWG community and that knowledge (or at least the good bits of it) need to be migrated forwards. People have also invested a great deal of effort in developing XML Schemas and may be reluctant to move on. This is all leading to TAG stuff rather than GUID stuff but as Steve and Rod and others point out the two are very closely connected - along with the protocol stuff... How much should the GUID debate assume that we are using current XML Schema based standards and how much should it assume a move to an RDF style approach - or doesn't it matter? Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 ------------------------------------- --------------------------------- Yahoo! FareChase - Search multiple travel sites in one click.

1 0

Re: Taxon debate synthesis?
by Patricia Mergen 22 Nov '05

22 Nov '05

Dear colleagues I managed now somehow (due to also a lot of real life work as James called this) to catch up with reading the many mails posted lately. I fully agree with Kevin's statement herunder that ID's should have no meaning. Anything meaningfull put into an ID can for various reasons change with time and be anyhow too confusing and misleading for those wanting "human readable" ID's. This would also be against the rule that an ID should be stable in time for "identification of an object". As far it has been reported to me the meaningless Assession Number used in Genbank/EMBL works technically fine. They have some problems with being sure to what species the sequence now really relays and if a voucher specimen is available or not, but It seems to me that this has more to do with the content provided to their system than with the chosen ID system? Best regards Pat Kevin Richards <RichardsK(a)LANDCARERESEARCH.CO.NZ> wrote: I agree with the idea of providing most of the information attached to a GUID in the metadata. After talking to the guys at IBM who wrote the LSID implementation, the data for an LSID was mainly intended for quite static data objects, such as documents and images. Most data, and especially dynamic data, is best returned as metadata. And RDF As for breaking opacity and having "meaning" within the GUID itself, this goes against a fundamental software principle that an ID should have no meaning. The namespaces of LSIDs are reasonably uncontrolled and hence this will no doubt result in erroneous assumptions. Anyway, in some cases you will know what the type of object a GUID is pointing to by the context that it resides in - eg the example Rod gave, <isMisspellingOf rdf:resource="urn:lsid:authority:namespace:123" /> - you will know that in your database you store links of misspellings to other taxon names. Kevin >>> deepreef(a)BISHOPMUSEUM.ORG 17/11/2005 9:47:43 a.m. >>> > Before we have a flurry of name flavours (yuck), I'd suggest that many > of these "flavours" are really relationships between names, Absolutely! -- I was using "flavours" in the sense that they would be defined in terms of relationships, not in terms of the data objects themselves. Sorry if it seemed I meant it that way. Perhaps there is value in establishing a metadata attribute for "IsBasionym" or something like that, but I think these things should really be defined by relationships among GUID-represented data objects, rather than as attributes of the data objects themselves. > Hence, I think before we embark on adding complexity, why not have > GUIDs for names and then specify relationships between these names? > This is what I've been doing with the LSIDs we serve here. Why not have GUIDs for NameUsages, and then specify relationships between these NameUsages? (simply because "names" are much more difficult to define than "NameUsages") > We could do with an ontology for these relationships so that, for > example, if somebody asks for the synonyms of name "x", and two names > are linked by the relationship "isBasionymOf" we recover that > relationship (in other words, our tools know that 'isBasionymOf" is a > kind of synonym). Sounds good to me! > Again, let's try and keep things simple. Agreed! And simple not so much for the sake of simplicity, but more for the sake of flexibility. > This leads to a much more general topic, but I think if we adopt RDF > for our metadata we gain a lot of query and inference tools "for free." > GUIDs by themselves are boring, it's the metadata that matters. Agreed! > > My general feeling is that most of the useful information is metadata, > > the > > only candidates for data (in my mind) being the literal text string > > (NameString), a ref pointer to a defined Documentation instance (if > > any), > > and perhaps position information (e.g. page) within the Documentation > > instance. All of these might be intially recorded in error, but could > > be > > corrected via the LSID revision id (version). > > I think everything about a name probably is metadata, and doing this > opens up the possibility of doing useful things with that metadata (see > above). In the LSID stuff we've been doing at Glasgow the only time we > provide data is if we are serving images, in which case it makes sense > to serve a stream of bytes (e.g., a TIFF image). In one sense, data > isn't that interesting (or, put another way in many cases it requires a > person to make sense of it, whereas computers can handle metadata). After having just spent the past couple hours brushing up my LSID "geek-speak", I agree completely with Rod on this. Aloha, Rich ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WARNING: This email and any attachments may be confidential and/or privileged. They are intended for the addressee only and are not to be read, used, copied or disseminated by anyone receiving them in error. If you are not the intended recipient, please notify the sender by return email and delete this message and any attachments. The views expressed in this email are those of the sender and do not necessarily reflect the official views of Landcare Research. Landcare Research http://www.landcareresearch.co.nz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --------------------------------- Yahoo! FareChase - Search multiple travel sites in one click.

1 0

Useful RDF/OWL/Semantic Web resources
by Ricardo Scachetti Pereira 22 Nov '05

22 Nov '05

Folks, While trying to learn more about RDF, OWL and the Semantic Web stuff to try to apply it to our GUID discussion, I came across some nice presentations on the Net: http://www.w3.org/Consortium/Offices/Presentations/SW_QA/#(14) - Semantic Web Q&A http://www.w3.org/Consortium/Offices/Presentations/RDFTutorial/ - Tutorial on Semantic Web Technologies I hope you find them as useful as I did. Enjoy, Ricardo _______________________________________________________ Yahoo! Acesso Grátis: Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/

1 0

Re: [tdwg-tapir] TapirLite
by "Döring, Markus" 22 Nov '05

22 Nov '05

Renato, just quickly. I hadnt enough time to think about your proposal yet. Just wanted to clearify what I meant in my last mail. The current query templates are referencing models, so they are depending on a model (1 to many relation). I wanted to "liberate" filter templates from any model. So the specification of a filter defining the semantics of GET parameters could be used for both, inventories and searches. You are right that we would need more for inventories, but its "atomised" enough with our GET definition of an inventory request. The reason why we needed filter templates is ONLY to be able to specify "atomised" get-parameters. Otherwise TAPIR lite services would have had to parse the full serialised filter string and it wold be possible for clients to ask for complex things. If I am correct we only need filter templates because TAPIR Lite wants to avoid complex filter strings. Am I right? Markus -----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Renato De Giovanni Gesendet: Dienstag, 22. November 2005 13:59 An: tdwg-tapir(a)lists.tdwg.org Betreff: Re: [tdwg-tapir] TapirLite Hi Markus and everybody, > So I was thinking why didnt we keep filters and output models entirely > separate from each other? Why not request a specific output model in a > search and also request a certain filter-parameter template? This > could then be reused for inventories where we dont need any output > model. Output models and filters are already separated. The outputModelGroup is made of structure, indexingElement and mapping. What brings output models and filters together are the query templates. > It would probably also look better in capabilities, if the output > model is listed separately for searches (see robs portal example) and > the query templates (maybe better filter templates?) are a distinct > section in capabilities that can be used in inventories ans searches? I still don't see how separate pre-defined filters can address pre- canned inventory operations. If I understood correctly, Donald wants to be able to use query templates (output model + parameterised filter) associated to inventory operations, not searches. That's something we haven't discussed. A query template for an inventory operation would look different from the one we have for searches. I think this goes more in the direction of making all operation elements belonging to an abstract substitution group called "operation". Requests could be a choice between any concrete operation or any template operation. In requests a template operation would be specified with an URI that should match one of the available templates advertised by the provider (unless the provider understands the basic underlying operation to dynamically parse and process the template definition). So operation templates would be defined externally also according to the protocol schema. In principle their body could be a search template or an inventory template (defined by a search template group or an inventory template group - the same structures used to validate and specify standard non-template operations). This really makes me feel that the current "query templates" (which I'm now calling operation templates in a more generic sense) should not belong to "search" in the capabilities response. So TapirLite providers could say that they do not support search and inventory, but they do support some "operation templates". On the other hand, the same search section under capabilities must provide a clear distinction for providers that do support one or more output models (like DiGIR2) and providers that support dynamic output models, leaving no space for the contradiction pointed in a previous message. I won't try to sort out more details unless this sounds like a good direction for all of us. After all changes that we recently proposed it seems we still need more effort to reach another "point of stability". Past experience shows that the process use to work like that, so I think we just need enough patience and more discussions. Hopefully the next point of stability is not so distant... Best regards, -- Renato _______________________________________________ tdwg-tapir mailing list tdwg-tapir(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org

2 1

Re: [tdwg-tapir] TapirLite
by "Döring, Markus" 22 Nov '05

22 Nov '05

Hello, reading Donalds message I had yet another idea. Donald was saying we are having parameterised inventories, but thats not true. We can only use the filter parameter with scans, but no predefined filters (similar to query templates). But it would be great and straight forward to have them. So I was thinking why didnt we keep filters and output models entirely separate from each other? Why not request a specific output model in a search and also request a certain filter-parameter template? This could then be reused for inventories where we dont need any output model. It would probably also look better in capabilities, if the output model is listed separately for searches (see robs portal example) and the query templates (maybe better filter templates?) are a distinct section in capabilities that can be used in inventories ans searches? It currently sounds like a good idea to me ! Markus -----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Donald Hobern Gesendet: Montag, 21. November 2005 23:43 An: rgales(a)ku.edu; 'Renato De Giovanni' Cc: tdwg-tapir(a)lists.tdwg.org Betreff: Re: [tdwg-tapir] TapirLite I'm afraid that I have been way too busy to keep up over the last few days, but I'd like to add my input one more time on TAPIRLite and TAPIR. I really see these as part of a continuum. There are two points on this continuum to which we have given names: TAPIRLite = ping + metadata + capabilities + a set of predefined parameterised scan or search (view) operations which have been defined somewhere using standard TAPIR scan and search definitions TAPIR = all of the above plus free-format scan and search operations and ability to handle any properly formed TAPIR request I can see really good uses for both of these with the TDWG standards and in the GBIF network, and quite frankly I will be in serious trouble if one of the two is not supported. I have a preference for keeping the name TAPIR somehow attached to both so that we emphasise what is common in our approaches. However I am not convinced that it is worth our while taking time to exclude any functional subset from what we will regard as "TAPIR". It will always be possible to define sets of capabilities which include search and scan behaviour but which are functionally useless (essential elements not being searchable, etc.). I suggest that we leave it to different communities (i.e. different TDWG content subgroups) to develop application profiles for the use of TAPIR with their data. For example, there should be a TDWG standard defining which elements should be searchable within a DwC data set, and perhaps documenting the minimal acceptable set of views which all specimen data sets MUST be able to support if they are to be accepted as TAPIRLite specimen or taxon concept providers. There could be contexts in which a community decides to make use of TAPIR solely with scan requests for some purpose, or solely with search requests. Why should we try to prevent this? Thanks for working so hard on all this. Donald --------------------------------------------------------------- Donald Hobern (dhobern(a)gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 --------------------------------------------------------------- -----Original Message----- From: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] On Behalf Of Robert Gales Sent: 21 November 2005 23:25 To: Renato De Giovanni Cc: tdwg-tapir(a)lists.tdwg.org Subject: Re: [tdwg-tapir] TapirLite Hi Renato, My comments inline... Renato De Giovanni wrote: > Hi Rob, > > It seems we agree on everything, I just have some quick comments... > > >>Further, say a >>portal wants to integrate specimen and taxon concept data, but the >>specimens implement TAPIR and all TCS providers are TAPIRLite. Once >>again, the developers must write an entirely custom portal. > > > This could become even more difficult if the TAPIR protocol leaves no > room for TapirLite implementations. Then the TCS networks would > probably be based on a completely different protocol, and the > integration would be more complicated. > > ... I'm definitely not arguing of making TAPIR so there is no room for TAPIRLite, but that anything that is not TAPIRLite must at minimum support both search and operations so there is at least a baseline of useful functionality (ping, metadata and capabilities aside) that all clients can take advantage of without requiring a large body of code just to handle the logic of understanding the capabilities and running the risk that there is no interoperability as Marcus has shown concern about. If I missed a similar argument on this list my apologies, I only recall discussions about what filter operations should/should not be required but nothing about TAPIR operations. > >>Assuming the above was present in the TAPIR protocol and a mixed >>network of TAPIR/TAPIR Lite implementations, the generic portal's >>basic logic might look something like the following: >> >>If Provider x is TAPIRLite: >> Find all query templates that match my output model >> >> As user constructs query, remove those query templates that could >> not possibly be used (missing concept, etc.) >> >> /* Likely more logic here if > 1 query templates are left >> * possibly with user interaction */ >> >>Else If Provider x is TAPIR: >> Ensure x supports my output model >> >> Can assume that search is available >> >> Can assume that operations (exception maybe "in") are supported >> >> /* If client is ambitious, may try to use any query templates >> defined >> * within search capabilities (would be same alg. as TAPIRLite), >> but * is optional */ > > > That's an interesting exercise. In this scenario, it seems that the > portal is configured to work with one specific output model (could be > more than one if we want to complicate things, the user could choose > one of them and the portal could know how to make transformations or > to dynamically filter providers). It would certainly complicate things depending on the output models. There are a couple of scenarios I see here. Scenario 1) Portals that support multiple models but of the same data object (ex. both DwC and ABCD) and 2) Portals that support multiple models of conceptually different data objects (ex. DwC and TCS). In the first case, I see there are potentially three ways to handle such a situation. 1) The portal is customizable by having a plug-in architecture that can handle transformations between two different schemas via XSLT/code. 2) The providers must support both output models. 3) The experimental custom output model mode is used on those providers that support it. There are benefits and drawbacks to all. In option 1) the portals architecture and configuration is a bit more complicated, but because the transformation can be accomplished by XSLT or code or a combination it can take into account semantic transformations. In option 2) there is a risk that there might be relevant data that cannot be accessed because a provider does not support the output models the portal desires, but this would be safest route. In option 3) potentially might run into some of the problems discussed in Madrid. In the second case where the portal is integrating different types of information, the portal really has multiple sets of providers that are able to be queried depending on the output models and concepts those providers have available. In the example there is the pool of providers that serve specimen data and the pool that serve taxonomic data. One (probably naive) way this could be handled is that the portal is configured with some sort of mapping that says something like (in English because I haven't really sat down to sketch this out in pseudocode): If User queries dwc:/ScientificName, also query providers with an output model of TCS using tcs:/DataSet/TaxonName/Simple Anything that is unmapped would result in queries only being transmitted to those providers that support the output model from which the concept in the filter originated. So dwc:/YearCollected would only query those providers in the pool supporting an output model of DwC and tcs:/DataSet/TaxonConcept/AccordingTo/Simple would only query those providers in the pool supporting an output model of TCS. What I haven't really thought much about is how to prevent (or what to do in the case it does happen) when someone creates a filter that uses concepts from each output model supported but are unmapped (as above not in terms of TAPIR mappings). Ex. dwc:/YearCollected = 1978 and tcs:/DataSet/TaxonConcept/AccordingTo/Simple = Jones. I guess one way to handle it would be to run each query on its pool of providers then merge them back based on the mappings. For example, with the the above example, the results after merging may contain only those specimens whose scientific name is equal to the TaxonName/Simple of those concepts authored by Jones. (Not sure if that is clear at all). > > When you say "Ensure x supports my output model" that actually means > "check that x supports custom output models and mapped the necessary > concepts, otherwise check that x supports any query template > associated to the output model I want", right? Hmmm...ok, I just took a look at the schema again to refresh my memory. I thought there was a place in the capabilities to define the output models that are supported (either that or I was influenced by the <FullService>/<LiteService> recommendation Marcus made). I see now that the only place this is defined is in the query templates. So the portal would need to iterate through the query templates to find out which ones supported the output model the portal was configured to be interested in. For TAPIR implementations the portal would most likely favor those query templates where there was no filter already existing so it wouldn't have to deal with reconciliation of the filter being defined by the user and the filter within the query template. For a generic client/portal I don't know that supporting custom output models would be the route I would go, but like with TAPIR we could probably leave a hook for it. > > By the way, looking at the capabilities response, is there any sense > on having a provider that supports the search operation, does not > accept custom output models, and does not define any query templates? I can't see how any provider that fit this description would be useful. If it does not support custom output models and doesn't define any query templates the provider would have no idea into what structure it should be marshaling the response of the query. > > Regards, > -- > Renato > > _______________________________________________ > tdwg-tapir mailing list > tdwg-tapir(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org Anyway, just some more slowly coalescing thoughts bouncing around the gray matter void, - rob _______________________________________________ tdwg-tapir mailing list tdwg-tapir(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org

3 2

AW: RDF/architecture/ontology - migration
by Robert Huber 22 Nov '05

22 Nov '05

RE: [TDWG-GUID] RDF/architecture/ontology - migrationDear all, I hope this contribution will arrive at the mailing list, for some reasons my last mail did't appear .. I would like to direct your attention to the handle.net system which basically is what is behind DOI. It can be found at http://www.handle .net. Using DOI itself would cause additional expenses, not too much, but has to be kept in mind. In contrary by choosing the handle.net and setting up an own handle server (or more), it would be for 'free'. The most important thing is that DOI / handle.net offers a system to _globally resolve_ unique identifiers! What do I mean by global resolution? Following the discussion here I sometimes have the impression that it is not completely understood what GUIDs are for and global resolving is the most important. A nice example was currently given to me by our 'DOI guru' here at the WDC-MARE: The national library of congress is using handle.net. The example has the id: loc.music/musdi.101. Very interesting is that you can use the DOI handle server to resolve to the particular document the id points to: http://dx.doi.org/loc.music/musdi.101 Other handle server would also direct to the correct location of the object: http://www.handle.net//loc.music/musdi.101 or http://hdl.loc.gov/loc.music/musdi.101 , The handle server at the National Library of Congress! Try the urls and you'll see that eg. DOI and NC redirect to the correct page. This is what this system makes so powerful! It works similar to the DNS system which allows to globally find the correct IP for a given web address. So it would not make a difference what identifying system you would choose, either the LSID or the DOI style or something else, as sson as it is globally unique and is handled by handle.net, the digital object which is behind the identifyer would be found. I hope this helps.. best regards, Dr. Robert Huber WDC-MARE / PANGAEA - www.pangaea.de, www.wdc-mare.org Stratigraphy.net - www.stratigraphy.net _____________________________________________ MARUM - Institute for Marine Environmental Sciences (location) University Bremen Leobener Strasse POP 330 440 28359 Bremen Phone ++49 421 218-65593, Fax ++49 421 218-65505 e-mail rhuber(a)wdc-mare.org, robert.huber(a)stratigraphy.net -----Ursprüngliche Nachricht----- Von: Taxonomic Databases Working Group GUID Project [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU]Im Auftrag von Chuck Miller Gesendet: Montag, 21. November 2005 22:13 An: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Betreff: Re: RDF/architecture/ontology - migration Do we want GUIDs that are dependent upon a specific protocol or schema? Seems like the ideal would be an approach that disconnects them so that the decisions for GUIDs and for protocols and schemas can be made separately. From what I've been hearing so far the GUID is embedded inside of something else, like LSID or DOI. That is, the unique identifier part is wrapped inside something that is understandable only by a specific protocol or locating mechanism. Is this unavoidable? Chuck Chuck Miller Chief Information Officer Missouri Botanical Garden 4344 Shaw Blvd St. Louis, MO 63119 -----Original Message----- From: Roger Hyam [mailto:roger@TDWG.ORG] Sent: Friday, November 18, 2005 4:40 AM To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Subject: [TDWG-GUID] RDF/architecture/ontology - migration This is carrying on from Steve's comments under the "Taxon debate synthesis?" thread. I started a new thread as it seemed to be getting a little deep and no longer fitting the title. Steve's comments are hitting the nail right on the head. From the conversations and thoughts I am having about architecture of TDWG standards all roads are leading to RDF - which is annoying because it makes writing balanced documents that compare the alternatives difficult :) Steve outlined one of the most promising paths forward for TDWG standards. Taking this route is not a matter of just saying "lets do it all in RDF" there would be a long way to go if we went this way - but at least we would be doing things the same way the rest of the semantic web world and that means there are tools and people out there to help. The one point Steve didn't stress is that RDF is the "bees knees" for data handshaking - i.e. combining data from different domains. This means that the extensibility and version problems that are our main hurdles as the moment will tend to go away. But have no fear there will be other problems to replace them. I am comfortable talking about GUIDs in terms of moving towards representing TDWG data in RDF. It certainly makes more sense of the GUID discussions to me. But... What we need to bear in mind is that there is a great deal of knowledge captured in XML Schema within the TDWG community and that knowledge (or at least the good bits of it) need to be migrated forwards. People have also invested a great deal of effort in developing XML Schemas and may be reluctant to move on. This is all leading to TAG stuff rather than GUID stuff but as Steve and Rod and others point out the two are very closely connected - along with the protocol stuff... How much should the GUID debate assume that we are using current XML Schema based standards and how much should it assume a move to an RDF style approach - or doesn't it matter? Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0