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

[tdwg-tapir] TaxonAPI
by Roger Hyam 30 Nov '05

30 Nov '05

Hi Everyone, I have been doing some work on a TaxonAPI. This is a high/low definition of the kind of thing I believe people publishing taxonomic data need to produce and people consuming it need to eat based on the work I have been involved in on TCS. It is framed as if it were a web service type of thing but I imagine that each of the method calls mentioned could equate to a Tapir template of some kind. I imagine a template containing a parameterized filter (not sure if those exist anymore). This is still work in progress as I need to define the list of parameters more closely and sort the greater than/less than issue for dates and a few other bits. Plus no one has seen it to comment on! You can read more about it here: http://www.tdwg.hyam.net/twiki/bin/view/TIP/TaxonAPI I would be most grateful for your comments. How does this fit with Tapir? Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

4 4

[tdwg-tapir] OGC standards and TAPIR
by Javier de la Torre 29 Nov '05

29 Nov '05

Dear all, I am still sending emails with these guys working with OGC standards and some times I have difficulties to explain why we are not using WFS for sharing our data. I check at the report from Renato and Markus and did not find explicit reasons, but I will try to put mines and please let me know if you find other reasons why do you think WFS is not the way to go... For sure I do not mean WFS as it is right now, but extending WFS to meet our needs. -OGC is a big consortium and it would be difficult to get our needs inserted in the standards. So if no one is going to worry about how we extend why should we worry about following them. -With WFS we would have to adapt our schemas to GML application schemas (that is substitution groups and we have to extend AbstractFeautureType). We would not like to have to change our standards described in XML schemas. -Standards like SDD can not make use of GML, mainly because WFS is a service for retrieving features of one single thing and not the relations between them. Do you agree with that or you want to add more reasons? Thanks. Javier.

4 5

[tdwg-tapir] Fwd: [ecoinfo] CFP: IEEE Web Services (ICWS 2006)
by Javier de la Torre 29 Nov '05

29 Nov '05

Sorry for crossporting, but... would be interesting to present TAPIR in a web service conference? Cheers. Begin forwarded message: > From: IEEE CFP <cfp(a)servicescomputing.org> > Date: 28 de noviembre de 2005 16:57:28 GMT+01:00 > To: "[no name]" <ecoinfo(a)ecoinformatics.org> > Subject: [ecoinfo] CFP: IEEE Web Services (ICWS 2006) > Reply-To: cfp(a)servicescomputing.org > > Apologies for cross-postings. Please send to interested colleagues > and students. THANKS! > > CALL FOR PAPERS > > 2006 IEEE International Conference on Web Services (ICWS 2006) > Celebrating the 60th Anniversary of IEEE Computer Society! > September 18-22, 2006, Hyatt Regency at O'Hare Airport, Chicago, USA > http://conferences.computer.org/icws/2006 > > Sponsored by IEEE Computer Society > Technical Committee on Services Computing (tab.computer.org/tcsc) > > The 2006 IEEE International Conference on Web Services (ICWS 2006) > will be part of the IEEE Computer Society Congress on Software > Technology and Engineering Practice (CoSTEP), celebrating the 60th > Anniversary of IEEE Computer Society! ICWS 2006 organizing > committee invites you to participate in the fourth year of ICWS in > Chicago, USA on 18-22 September 2006. > > ICWS has been a prime international forum for both researchers and > industry practitioners to exchange the latest fundamental advances > in the state of the art and practice of Web Services. ICWS also > aims to identify emerging research topics and define the future of > Web Services. Over the past four years, ICWS has grown steadily, > attracting over 200 participants on a regular basis. ICWS 2005 was > held on July 11-15, 2005 in Orlando, Florida, USA; ICWS 2004 was > held on July 6-9, 2004 in San Diego, California, USA; ICWS 2003 was > held on June 23-26, 2003 in Las Vegas, Nevada, USA. > > ICWS 2006 will be co-located with the 2006 IEEE International > Conference on Services Computing (SCC 2006), the 30th Annual > International Computer Software and Applications Conference > (COMPSAC 2006), and the 2006 IEEE Workshops on Software Technology > and Engineering Practice (STEP 2006). IEEE Services Oriented > Architecture (SOA) Industry Summit and IEEE International Services > Computing Contest will also be featured at this joint event. > > The technical program will include refereed paper presentations, > panels, and poster sessions in both research and industry tracks. > Workshops and tutorials will run before and throughout the conference. > > ICWS 2006 program seeks original, unpublished research papers > reporting substantive new work in various aspects of Web services. > Papers must properly cite related work and clearly indicate their > contributions to the field of Web services. Topics of interest > include but not limited to: > > * Mathematical Foundations for Web Services Computing > * Web Services-based Service Oriented Architecture > * Web Services Modeling > * Web Services Standards and Implementation Technologies > * Web Services Specifications and Enhancements (e.g., UDDI, SOAP, > WSDL) > * Web Services Discovery > * Web Services Composition and Integration > * Web Services Invocation > * QoS for Web Services (e.g., security, privacy, reliability, > performance, fault tolerance, etc.) > * Web Services Assessment (i.e., validation & verification) > * Web Services-based Testing Methodologies > * Web Services-based Software Engineering > * Web Services-based Project Management > * Semantic Web Services > * IT Infrastructure Management for Web Services > * Solution Management for Web Services > * Multimedia Web Services > * Web Services-based Business Process Management > * Web Services-based Mobile Computing > * Web Services-based Grid Applications (e.g. OGSA) > * Domain Specific Web Services Applications and Solutions > > All submitted manuscripts will be peer-reviewed by at least 3 > program committee members. Accepted papers will appear in the > conference proceedings in both hardcopy and on-line version > published by the IEEE Computer Society. Extended versions of > selected best papers published in the ICWS 2006 will be invited for > publication in the International Journal of Web Services Research > (JWSR), the International Journal of Business Process Integration > and Management (IJBPIM), and the International Journal of Grid and > Utility Computing (IJGUC). Both the ICWS Proceedings and JWSR are > included in EI Compendex. > > Submitted manuscripts will be limited to 8 (IEEE Proceedings style) > pages and required to be formatted using the IEEE Proceedings > template. Electronic submission of manuscripts (in PDF or Word > format) is required. Detailed instructions for electronic paper > preparation and submission, panel proposals, tutorial proposals, > and review process can be found at http://conferences.computer.org/ > icws/2006/. At least one author of each accepted paper is required > to register for the conference and present the paper. One Best > Paper award and between one to three Best Student Paper Awards will > be granted at ICWS 2006. The first author of the best student > papers must be full-time student. > > If your paper is application or solution oriented, you can consider > submitting it to ICWS 2006 Industry Track via its dedicated online > submission and review system. Manuscripts submitted to the Research > Track focusing on application or solution descriptions may be > recommended to the Industry Track for further considerations. > Submitted papers with novel ideas but not accepted by the Research > Track and Industry Track due to space limitation may also be > recommended to the Work-in-Progress Track. > > Important Dates: > Abstract Submission Deadline: January 16, 2006 > Paper Submission Due Date: January 16, 2006 > Decision Notification (Electronic): April 24, 2006 > Camera-Ready Copy Due Date & Pre-registration Due: May 31, 2006 > > General Chairs: > Liang-Jie (LJ) Zhang, Ph.D., IBM T.J. Watson Research, USA, zhanglj > AT us.ibm.com > Frank Leymann, University of Stuttgart, Germany, frank.leymann AT > informatik.uni-stuttgart.de > > Program Chairs: > Ephraim Feig, Ph.D., Kintera, Inc., efeig AT kintera.com > Anup Kumar, Professor, CECS Department, University of Louisville, > USA, ak AT louisville.edu > > Program Vice Chair: > Jia Zhang, Ph.D., Northern Illinois University, jiazhang AT cs.niu.edu > > Workshop Chairs > > Malu G. Castellanos, Ph.D. > HP Laboratories, USA > > Jian Yang, Ph.D. > Associate Professor, Macquaire University, Australia > > Industry Track Chair > > Wu Chou, Ph.D. > Avaya Labs Research, Avaya, USA > > IEEE SOA Industry Summit Chairs > > Ali Arsanjani, Ph.D. > Chief Architect, SOA and Web Services Center of Excellence > IBM Global Services, USA > > Tony Shan > Lead Systems Architect, Wachoiva Bank, USA > > Tutorial Chairs > > Schahram Dustdar, Ph.D. > Professor, Vienna University of Technology, Austria > > Andreas Wombacher, Ph.D. > PostDoc Fellow, University of Twente, The Netherlands > > Job Fair Chair > > Sandeep Purao, Ph.D. > Associate Proessor, Pennsylvania State University, USA > > Panel Chairs > > Frank Ferrante > Editor in Chief, IEEE IT Professional Magazine, USA > > Ling Liu, Ph.D. > Associate Professor, Georgia Institute of Technology, USA > > Hsing Kenny Cheng, Ph.D. > Associate Professor, University of Florida, USA > > Work-in-Progress Chair > > Graciela Gonzalez, Ph.D. > Assistant Professor, Sam Houston State University, USA > > Publicity Chairs > > Jeff Voas, Ph.D. > Director, Systems Assurance > Science Applications International Corporation (SAIC), USA > > Elena Ferrari, Ph.D. > Professor, University of Insubria at Como, Italy > > Steve Miller, Ph.D. > Professor, Dean of the School of Information Systems > Singapore Management University, Singapore > > Publication Chair > > Haifei Li, Ph.D. > Assistant Professor, Union University, USA > > IEEE APSCC 2006 Liaison > > Hai Jin, Ph.D. > Professor and Dean, School of Computer > Huazhong University of Science and Technology, China > > IEEE Services Computing Contest Chairs > > Zhixiong Chen, Ph.D. > Associate Professor, Mercy College, USA > > Charles A. Shoniregun, Ph.D. > University of East London, UK > > Yuan-Chwen You, Ph.D. > Founder, Creative Entrepreneurship Consulting, Inc., Taiwan > > Program Committee: > > Grigoris Antoniou (University of Crete/Institute of Computer > Science FORTH, Greece) > Mikio Aoyama (Nanzan University, Japan) > Ali Arsanjani (IBM Global Services, USA) > Malcolm Atkinson (University of Edinburgh, UK) > Boualem Benatallah (University of New South Wales, Australia) > Elisa Bertino (Purdue University, USA) > Ken Birman (Cornell University, USA) > Athman Bouguettaya (Virginia Tech., USA) > Paul Buhler (College of Charleston, Charleston, SC USA) > Christoph Bussler (Cisco Systems, USA) > Jorge Cardoso (University of Madeira, Portugal) > Malu G. Castellanos (HP Labs, USA) > Jeane Chen (Kintera, USA) > Ying Chen (IBM China Research Lab, China) > Wu Chou (Avaya Labs Research, Avaya , USA) > Alok Choudhary (Northwestern University, USA) > Vassilis Christophides (University of Crete/Institute of Computer > Science FORTH, Greece) > Umeshwar Dayal (HP Labs, USA) > Stefan Dessloch (Kaiserslautern University of Technology, Germany) > Asuman Dogac (Middle East Technical University, Turkey) > Jiang Du (Queensland University of Technology, Australia) > Schahram Dustdar (Vienna University of Technology, Austria) > Phillip Ein-Dor (Tel-Aviv University, Israel) > Vadim Ermolayev (Zaporozhye State University, Ukraine) > Dieter Fensel (DERI, Ireland & University of Innsbruck, Austria) > Elena Ferrari (Politiche e dell'Informazione, University of > Insubria at Como, Italy) > Marcus Fontoura (Yahoo Research, USA) > Piero Fraternali (Politecnico di Milano, Italy) > Casey K. Fung (Boeing Phantom Works, USA) > Martin Gaedke (University of Karlsruhe, Germany) > George M. Galambos (IBM Canada) > Shahram Ghandeharizadeh (University of Southern California, USA) > Graciela Gonzalez (Sam Houston State University , USA) > Vijay K. Gurbani (Lucent Technologies/Bell Labs Innovations, USA) > Abdelsalam (Sumi) Helal (University of Florida, USA) > Alan R. Hevner (University of South Florida, USA) > Michael N. Huhns (University of South Carolina, USA) > Rick Hull (Lucent Technologies, Bell Labs, USA) > Patrick C. K. Hung (University of Ontario Institute of Technology, > Canada) > Varghese S. Jacob (University of Texas at Dallas, USA) > Hemant Jain (University of Wisconsin - Milwaukee, USA) > Ralph Johnson (University of Illinois at Urbana-Champaign, USA) > Anupam Joshi (University of Maryland, Baltimore County, USA) > Roger (Buzz) King (University of Colorado at Boulder, USA) > Hiroyuki Kitagawa (University of Tsukuba, Japan) > Domenico Laforenza (Information Science and Technologies Institute > (ISTI), USA) > Herman Lam (University of Florida, USA) > Konstantin Läufer (Loyola University Chicago, USA) > M. Lenzerini (DIS Dipartimento di Informatica e Sistemistica, Italy) > Frank Leymann (University of Stuttgart, Germany) > Haifei Li (Union University, USA) > Wei Li (Institute of Computing Technology, Chinese Academy of > Sciences, China) > Geng Lin (Cicso Systems, USA) > Ling Liu (Georgia Institute of Technology, USA) > Bertram Ludaescher (University of California at Davis, USA) > J.P. Martin-Flatin (UQAM, Canada) > XS (Xin Sheng) Mao (IBM China Software Development Laboratory > (CSDL), China) > Hiroshi Maruyama (IBM Research, Japan) > Carolyn McGregor (University of Western Sydney, Australia) > Dennis McLeod (Univeristy of Southern California, USA) > Hong Mei (Beijing University, China) > Xiannong Meng (Bucknell University, USA) > Dejan S. Milojicic (HP Laboratories, USA) > Simanta Mitra (Iowa State University, USA) > Tadao Murata (University of Illinois at Chicago, USA) > Jeff Offutt (George Mason University, USA) > Thomas E. Potok (Oak Ridge National Lab (ORNL), USA) > Thierry Priol (Inria, France) > Calton Pu (Georgia Tech, USA) > Norbert Ritter (University of Hamburg, Germany) > Dumitru Roman (University of Innsbruck / DERI Innsbruck, Austria) > Steve Ross-Talbot (Enigmatec Corporation, Germany) > Atul Sajjanhar (School of Information Technology, Australia) > Vipul Shah (Tata Consultancy Services America, USA) > Amit Sheth (University of Georgia, USA) > Simon Shim (San Jose State University, USA) > Munindar P. Singh (North Carolina State University, USA) > Il-Yeol Song (Drexel University, USA) > Judith Stafford (Tufts University, USA) > Rudi Studer (University Karlsruhe, Germany) > Jianwen Su (University of California at Santa Barbara, USA) > Stanley Su (University of Florida, USA) > Katia Sycara (Carnegie-Mellon University, USA) > Stephan Tai (IBM T.J. Watson Research Center, USA) > Jeffrey Tsai (University of Illinois at Chicago, USA) > Jeffrey Voas (Science Applications International Corporation, USA) > Graham Williams (Togaware, Australia) > Joseph Williams (Microsoft, USA) > Stephen J.H. Yang (National Central University, Taiwan) > Clement Yu (University of Illinois at Chicago, USA) > Liang-Jie Zhang (IBM T.J. Watson Research, USA) > Yanchun Zhang (Victoria University, Melbourne, Australia) > Hong Zhu (Oxford Brookes University, UK) > > > Technical Steering Committee: > > Carl K Chang (Iowa State University, USA) > Ephraim Feig (Kintera Inc, USA) > Hemant Jain (University of Wisconsin- Milwaukee , USA) > Frank Leymann (University of Stuttgart, Germany) > Calton Pu (Georgia Tech, USA) > Ming-Chien Shan (Hewlett-Packard, USA) > Jeffrey Tsai (University of Illinois at Chicago, USA) > Liang-Jie Zhang (IBM T.J. Watson Research Center, USA) > > > _______________________________________________ > Ecoinfo mailing list > Ecoinfo(a)ecoinformatics.org > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/ecoinfo

1 0

Re: [tdwg-tapir] OGC standards and TAPIR
by "Döring, Markus" 29 Nov '05

29 Nov '05

Hi, some stupid question regarding WFS. Does all feature data in WFS need to be geo referenced? If so, then this is probably the biggest drawback as taxon data usually isnt and even a lot of our observations or specimens arent at least not properly referenced. But I guess you can share purely non geographic information as well? Markus -----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Javier privat Gesendet: Dienstag, 29. November 2005 15:00 An: tdwg-tapir(a)lists.tdwg.org Betreff: Re: [tdwg-tapir] OGC standards and TAPIR Hi all, Do not misunderstand me. I did not want to mean that it could be a good idea to join the OGC and use their standards. I am in a parallel discussion with someone from the OGC community and I wanted to have some arguments... In projects like Geoserver and in deegree (open source implementations of WFS) they have to deal with the same problems we have of mapping relational databases to user schemas (that is GML application schemas for them). It would be great to be able to share code and ideas with them, but I know this may be more work than not contact at all... They have already some OS libraries, like Geotools, for dealing with OGC protocols, in the same way we are going to create libraries for TAPIR. Being involved in bigger communities like this one could benefit us, right now there is no one apart of us interested in our software. But again I am not sure if this would not actually mean more work and less flexibility... and in any case we are probably too deep in our things to consider something like this, so I do not want to open this discussion and better concentrate in finishing what we have. Just for your knowledge I have to say that I think we are more advance than Geoserver, at least, in solving the mapping problem :) Just for you to feel better jeje. Javier. On 28/11/2005, at 17:47, Roger Hyam wrote: > Before we jump in bed with GML (which I have been in favour of in the > past) it is worth looking at the other side. > > This is an interesting article/opinion on GML: > > http://www.mapbureau.com/gml/ > > And somewhere down this page is a blog by a guy talking to Ron Lake > about getting RDF stuff in GML or visa versa which makes good reading. > > http://danbri.org/words/category/general/ > > If we think about integration of technologies then it seems to me that > we want to be able to plug into as many other domains as possible. If > some one wants to pass information around about people or buildings or > DNA along side herbarium specimen data then we should not make up a > schema for it the user should be able to use any of a whole bunch of > widely acceptable, cross domain ontologies/ vocabularies. They should > pick the one most suitable to them. > > If we go with pure GML then we may end up having to invent or port > things to it that aren't of interest to the geographic community. > GML may be a bunch of cartographers trying to invent their own > semantic web. GML applications may be nearly as far away from plugging > in to "everything else" as we are. > > So maybe a one night stand or an open marriage but not total > commitment unless we can see a path to more generic W3C standards - is > what I'm thinking at the moment. > > All the best, > > Roger > > > Javier de la Torre wrote: >> Dear all, >> >> I am still sending emails with these guys working with OGC standards >> and some times I have difficulties to explain why we are not using >> WFS for sharing our data. I check at the report from Renato and >> Markus and did not find explicit reasons, but I will try to put mines >> and please let me know if you find other reasons why do you think WFS >> is not the way to go... For sure I do not mean WFS as it is right >> now, but extending WFS to meet our needs. >> >> -OGC is a big consortium and it would be difficult to get our needs >> inserted in the standards. So if no one is going to worry about how >> we extend why should we worry about following them. >> >> -With WFS we would have to adapt our schemas to GML application >> schemas (that is substitution groups and we have to extend >> AbstractFeautureType). We would not like to have to change our >> standards described in XML schemas. >> >> -Standards like SDD can not make use of GML, mainly because WFS is a >> service for retrieving features of one single thing and not the >> relations between them. >> >> Do you agree with that or you want to add more reasons? >> >> Thanks. >> >> Javier. >> >> _______________________________________________ >> tdwg-tapir mailing list >> tdwg-tapir(a)lists.tdwg.org >> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org >> >> > > -- > > ------------------------------------- > Roger Hyam > Technical Architect > Taxonomic Databases Working Group > ------------------------------------- > http://www.tdwg.org > roger(a)tdwg.org > +44 1578 722782 > ------------------------------------- > _______________________________________________ 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] TaxonAPI
by "Döring, Markus" 29 Nov '05

29 Nov '05

So inventories dont seem to be important for any of the taxon APIs. Do we then still want to provide parameterised inventories? -----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Dave Vieglais Gesendet: Montag, 28. November 2005 18:40 An: roger(a)tdwg.org Cc: tdwg-tapir(a)lists.tdwg.org Betreff: Re: [tdwg-tapir] TaxonAPI Hi Roger, You might also like to examine http://seek.ecoinformatics.org/Wiki.jsp?page=TOSAPISignatures The interfaces and implementation have been developed as part of the SEEK project. regards, Dave V. Roger Hyam wrote: > Hi Everyone, > > I have been doing some work on a TaxonAPI. This is a high/low > definition of the kind of thing I believe people publishing taxonomic > data need to produce and people consuming it need to eat based on the > work I have been involved in on TCS. > > It is framed as if it were a web service type of thing but I imagine > that each of the method calls mentioned could equate to a Tapir > template of some kind. I imagine a template containing a parameterized > filter (not sure if those exist anymore). > > This is still work in progress as I need to define the list of > parameters more closely and sort the greater than/less than issue for > dates and a few other bits. Plus no one has seen it to comment on! > > You can read more about it here: > > http://www.tdwg.hyam.net/twiki/bin/view/TIP/TaxonAPI > > I would be most grateful for your comments. > > How does this fit with Tapir? > > Roger > _______________________________________________ tdwg-tapir mailing list tdwg-tapir(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org

3 2

[tdwg-tapir] TAPIR open issues
by "Döring, Markus" 29 Nov '05

29 Nov '05

Hello, as we were planning to freeze the tapir development by the end of the year, we would need to hurry a bit. I lost a little bit track of the open issues. So I would like to ask everyone to bring up the issues he still remembers to be solved. >>>From what I remember, the discussion was not closed on: - parameterised inventories. Do we need them, how should they look? - flexible capabilities. Do we allow services to implement a custom subset of TAPIR, or is it better to declare services either as Lite or Full? Markus

2 1

Re: [tdwg-tapir] OGC standards and TAPIR
by "Döring, Markus" 28 Nov '05

28 Nov '05

and then there is no scan operation - which we liked for indexing for example. m -----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Javier privat Gesendet: Montag, 28. November 2005 16:39 An: tdwg-tapir(a)lists.tdwg.org Betreff: [tdwg-tapir] OGC standards and TAPIR Dear all, I am still sending emails with these guys working with OGC standards and some times I have difficulties to explain why we are not using WFS for sharing our data. I check at the report from Renato and Markus and did not find explicit reasons, but I will try to put mines and please let me know if you find other reasons why do you think WFS is not the way to go... For sure I do not mean WFS as it is right now, but extending WFS to meet our needs. -OGC is a big consortium and it would be difficult to get our needs inserted in the standards. So if no one is going to worry about how we extend why should we worry about following them. -With WFS we would have to adapt our schemas to GML application schemas (that is substitution groups and we have to extend AbstractFeautureType). We would not like to have to change our standards described in XML schemas. -Standards like SDD can not make use of GML, mainly because WFS is a service for retrieving features of one single thing and not the relations between them. Do you agree with that or you want to add more reasons? Thanks. Javier. _______________________________________________ tdwg-tapir mailing list tdwg-tapir(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org

1 0

Re: Two Scenarios
by Dag Terje Endresen 25 Nov '05

25 Nov '05

Hi all, Do we move to fast into the mechanism on how to resolve the GUID before we have defined how the GUID will look like? Sorry if I am to jump too fast on this train in my remarks below. I think that what Arthur and Roger was touching, is that we already have various production mechanisms for resolving metadata object relations implemented. Many organizations already have systems established and populated with metadata and logic to resolve information and relation for the objects that we will assign GUIDs to? I believe this is in part why we are interested to come up with an improved method to address this task? I know we in the European seed bank community have discussed even the option to receive and redirect requests on living biological material (seeds) from crop metadata portals. The portals themselves do not own (or control) either the metadata nor the physical seed samples. There are also services providing additional or corrections to the published metadata on the seed samples. All these activities struggle to achieve a stable link back to the original physical sample and would be significantly improved by a stable GUID mechanism to resolve this link. There are methods and logic implemented to address this problem. Often the link back is lost, and often severe manual work is done to currate the link between these objects. So I think there would be a transition period to migrate the logic to RDFs and to re-engineer the mechanisms to resolve the link between the metadata objects and between the metadata and the physical sample. I am not very well into the theory of the RDF and need to read up before I would be able to start to migrate the logic we have established to resolve relationsships in the seed bank community to RDF. I would however be happy to do the reading if this is the standard GUID representation we will go for. I hope however we will not build the GUID resolver so complex that knowledge about how to use the GUID will be too much of a limitation...? For example if the GUID itself would be something you could paste directly into a browser and get information about the object, would less user threshold than if you would need to install some kind of RDF client to be able to "use" the GUID? We should perhaps start with a very basic GUID solution and remember to think about how this can be integrated with existing mechanisms. Not all existing solutions involve schemas described in XML. And I also believe that migrating even logic described in XML to RDFs would provide us with some challenges? This is why the call for use cases by Donald is important? Cheers Dag Terje Quoting Roderic Page <r.page(a)BIO.GLA.AC.UK>: > On 25 Nov 2005, at 15:34, Roger Hyam wrote: > > > > > But wait... there is more. As Arthur points out we already have > most > > of this stuff defined. TCS encapsulates a whole load of semantics > > > about nomenclatural relationship (types of type etc) and > TaxonConcept > > relationship (child taxon of, hybrid parent of etc) and ABCD has > > similar knowledge about collections. A great deal of > re-engineering > > and transition is involved. We mustn't go throwing any babies out > with > > the bath water. > > Maybe I'm missing something (since I've avoided XML schema like the > > plague), but given that RDF is (usually) expressed in XML, shouldn't > we > be able with a minimum of fuss to "port" the relevant bits from an > XML > schema to an RDF schema? Maybe I'm being naive but I don't see why > this > is such an engineering nightmare. > > > > > Also serving this stuff may be problematic.... > > Serving what stuff? > > > > > > So yes GUID+RDF seems to solve most every problem just at the > moment. > > > > Roger > > > > > > > > Arthur Chapman wrote: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_description.pdf > >> > >> 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 == > >> > >> > > > > -- > > > > ------------------------------------- > > Roger Hyam > > Technical Architect > > Taxonomic Databases Working Group > > ------------------------------------- > > http://www.tdwg.org > > roger(a)tdwg.org > > +44 1578 722782 > > ------------------------------------- > > > > > ------------------------------------------------------------------------ > > ---------------------------------------- > 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 Roderic Page 25 Nov '05

25 Nov '05

On 25 Nov 2005, at 15:34, Roger Hyam wrote: > > But wait... there is more. As Arthur points out we already have most > of this stuff defined. TCS encapsulates a whole load of semantics > about nomenclatural relationship (types of type etc) and TaxonConcept > relationship (child taxon of, hybrid parent of etc) and ABCD has > similar knowledge about collections. A great deal of re-engineering > and transition is involved. We mustn't go throwing any babies out with > the bath water. Maybe I'm missing something (since I've avoided XML schema like the plague), but given that RDF is (usually) expressed in XML, shouldn't we be able with a minimum of fuss to "port" the relevant bits from an XML schema to an RDF schema? Maybe I'm being naive but I don't see why this is such an engineering nightmare. > > Also serving this stuff may be problematic.... Serving what stuff? > > So yes GUID+RDF seems to solve most every problem just at the moment. > > Roger > > > > Arthur Chapman wrote: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_description.pdf >> >> 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 == >> >> > > -- > > ------------------------------------- > Roger Hyam > Technical Architect > Taxonomic Databases Working Group > ------------------------------------- > http://www.tdwg.org > roger(a)tdwg.org > +44 1578 722782 > ------------------------------------- > > ------------------------------------------------------------------------ ---------------------------------------- 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 Roger Hyam 25 Nov '05

25 Nov '05

Adding to what Rod said the important thing to point out is that using GUID+RDF you can reason about resources you don't own. So the herbarium that discovers it has a duplicate of something in another herbarium can publish the fact without involving the other herbarium. In fact I can make assertions I have only just invented about things in two collections that have never heard of me. But wait... there is more. As Arthur points out we already have most of this stuff defined. TCS encapsulates a whole load of semantics about nomenclatural relationship (types of type etc) and TaxonConcept relationship (child taxon of, hybrid parent of etc) and ABCD has similar knowledge about collections. A great deal of re-engineering and transition is involved. We mustn't go throwing any babies out with the bath water. Also serving this stuff may be problematic.... So yes GUID+RDF seems to solve most every problem just at the moment. Roger Arthur Chapman wrote: > 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 == > > -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0