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

[tdwg-tapir] Schema modification: r331 - trunk/protocol
by tdwg-tapir＠lists.tdwg.org 22 Nov '05

22 Nov '05

Author: markus Date: 2005-11-22 11:16:16 +0100 (Tue, 22 Nov 2005) New Revision: 331 Modified: trunk/protocol/tapir.xsd Log: and again. comment removed. Modified: trunk/protocol/tapir.xsd =================================================================== --- trunk/protocol/tapir.xsd 2005-11-22 10:09:24 UTC (rev 330) +++ trunk/protocol/tapir.xsd 2005-11-22 10:16:16 UTC (rev 331) @@ -2,7 +2,6 @@    - <xsd:schema xmlns="http://www.tdwg.org/schemas/tapir/datasource/1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.tdwg.org/schemas/tapir/datasource/1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0" xml:lang="EN">

1 0

[tdwg-tapir] Schema modification: r330 - trunk/protocol
by tdwg-tapir＠lists.tdwg.org 22 Nov '05

22 Nov '05

Author: markus Date: 2005-11-22 11:09:24 +0100 (Tue, 22 Nov 2005) New Revision: 330 Modified: trunk/protocol/tapir.xsd Log: A test modification of the protocol to see if the svn hook works and sends email to the tapir list. Modified: trunk/protocol/tapir.xsd =================================================================== --- trunk/protocol/tapir.xsd 2005-11-21 17:35:52 UTC (rev 329) +++ trunk/protocol/tapir.xsd 2005-11-22 10:09:24 UTC (rev 330) @@ -2,6 +2,7 @@    + <xsd:schema xmlns="http://www.tdwg.org/schemas/tapir/datasource/1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.tdwg.org/schemas/tapir/datasource/1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0" xml:lang="EN">

1 0

[tdwg-tapir] ideas & TapirLite
by "Döring, Markus" 21 Nov '05

21 Nov '05

Hi, talking to Anton today we were wondering if it makes sense to allow a tapir client to embed its own request-id into the tapir headers for later identification of asynchronous and distributed messages. Currently we would need to identify a message by its sendtime (vague) and source. Does this make sense? Does anyone know how other people deal with this problem? ----------- The other thoughts were about TapirLite. We both think its a very bad idea to push all responsibility to the client by allowing any TAPIR service to be very minimalistic. If a client should be able to contact services that have different operators, operations and concepts, then I dont think we will get anything interoperable. I still prefer that these things must exist in the most basic TAPIR service. Otherwise we should call it different - maybe even TAPIR Lite as a valid subset: - all operations - all logical operators - the main COPs (<=> like) Cconcepts and response models can be optional without much problems I think. What do you think? should we sacrifice all this to have few clients but many providers? BTW, I think we didnt specify anywhere in capabilities if GET or XML Messaging is supported. So the idea is to always have both for all services, right? Markus

6 9

Re: RDF/architecture/ontology - migration
by Ricardo Scachetti Pereira 21 Nov '05

21 Nov '05

Roger, You've raised a very important issue. Deciding whether our community should continue to use XML Schema or adopt RDF, (or anything else for that matter) is a sizeable discussion. Although it is intrinsically related to GUIDs, the discussion is well beyond the scope and timeframe of this group. What that tells us is that whatever GUID solution we come up with, it should leave some flexibility to support either one of the approaches (i.e., this is a new requirement). So, answering your question (and Chuck's), it shouldn't matter much. At least not if we are talking about the underlying GUID infrastructure (the boring part, as some of us say ;) To make it more concrete, take LSID for example. It already offers a hook to solve this kind of problem. Roughly, that's the protocol to resolve a GUID using LSIDs: 1) Client has a LSID and wants to resolve it. It queries a authority discovery service (implemented using DNS) to know who can resolve that LSID 2) Client discovers who can resolve that LSID. Client then queries the resolving authority to find out how to get data or metadata regarding that LSID. 3) When requesting metadata, the client can specify what kinds of metadata it wants back. Those types can be any IANA media type (i.e. HTTP Content-types), such as x-application/rdf+xml, x-application/xmi+xml, xml, xml-dtd, etc. Using that feature one can implement metadata services responding using XML Schema or RDF independently. So, at least for LSIDs, we have the hook that will allow GUID group to progress without the need to answer to your original question. But that will buy us only little time. At some point, when we turn back to the metadata part of our GUID solutions and the onthologies (remember, those discussions about what gets GUIDs for specimens and taxon?). That's when we need to address the XML Schema vs. RDF question. But at least, we can still separate the basic GUID framework from the implementation details of the metadata layer. Then, depending on how the discussion progresses in other forums (TAG, probably), we can implemen either one (or both). Finally, to address Matt's comments, I'm not suggesting we leave the resolution loose. I'm just proposing that we leave it open until we get a clearer map of how to progress. Cheers, Ricardo Roger Hyam 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! Acesso Grátis: Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/

1 0

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

21 Nov '05

I would like to get into the lite idea a bit more in detail. Lets start with the list of expected "levels" of tapir compliant services: 1- a full TAPIR service incl an experimental dynamic custom output model 2- a full TAPIR service restricted to certain output models identfied via a list of URLs pointing to the output model definition documents 3- a TAPIR Lite that only wants to accept certain parameters for fixed queries. The main idea as I can see is to have a limited list (maybe only 1?) of query templates here (reminder: QTs are filters & a URL reference to an output model) that define the accepted parameters. I assume this service also only works via http GET and not through xml messaging. The difference between level 1 & 2 is quite small (not necessarily for implementations though). The list of accepted output models simply go into the capabilities of a provider and a client can easily identfy if it is able to communicate with a datasource service. A level 3 TAPIR lite service is quite different from the others. Essentially its a regular GET based webservice that can be described by a WSDL, cause no serialised filter is allowed and the response model is fixed. If we really want to define these kind of simple services with the same protocol schema, what should be its "capabilities"? - only http GET invocation, no xml messaging - the TAPIR envelope should be supported for responses - ping, metadata, capabilites should work - no inventory operation - no (complex) filters or variables, only parameters If only parameters are accepted, then this is not a real search. In the old protocol this was a distinct "view" operation. What we want here is exactly this again. A service only available via http get and parameters. A list of accepted query templates would be enough and no operators, variables and alike need to be supported. The current definition of capabilities does only allow to specify http-GET only services or the accepted list of query templates by the way! A new adhoc idea: what about defining these 3 levels and allowing no other intermediate compliance? Then we can reduce the capabilities a lot, a lot of burden would be removed from clients and we would get more interoperability? Just a quick thought when looking at the above. We could make it as simple as this: <FullService accept_custom_models="false"> <supportedModels> <model location="URI" namespace=""> ... </supportedModels> <concepts> <concept id="..." /> ... </concepts> </FullService> or <LiteService> <supportedQueryTemplates> <template location="URI"> <parameter name="" /> ... </template> ... </supportedQueryTemplates> </LiteService> What do you think? I am really a bit afraid of ending up with different services that implement only bits of the specification. We are about to move all burden towards the clients which for my feeling should be easy to create as a researcher with just simple programming knowledge. Sorry to raise this issue again and especially for this drastic new suggestion. It came up while writing this mail, so dont take it for a well thought idea. I just want to think a bit more about the problems involved in having variable and mutating tapir services. Markus -----Ursprüngliche Nachricht----- Von: Roger Hyam [mailto:roger@tdwg.org] Gesendet: Freitag, 18. November 2005 10:32 An: Donald Hobern Cc: Döring, Markus; tdwg-tapir(a)lists.tdwg.org Betreff: Re: [tdwg-tapir] ideas & TapirLite As TapirLite champion I do have a problem with having to implement all the operators. I just want to be pretty and dumb! I don't have a problem with the concept of a named subset protocol i.e. Tapir (the real thing) and TapirLite (the not so bright second cousin). Are there some use cases somewhere listing what Tapir clients are expected to call or some statistical break down of what kinds of queries are run against existing BioCASE and DiGIR providers? Roger Donald Hobern wrote: > Markus, > > Doesn't "all operations" imply that the provider must implement > generic search operations? Isn't a large part of the reason for TAPIR > Lite the need to support "databases" that cannot be mapped using the > standard RDBMS mapping and which are just trying to emulate common views? > > I would say that these should be supported but that each TDWG content > subgroup needs to define a set of (web service) interfaces that must > be supported by any compliant provider. If they can handle this set > of views, they may appear as TAPIR providers. > > Or did I miss something? > > 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 "Döring, Markus" > Sent: 17 November 2005 16:25 > To: tdwg-tapir(a)lists.tdwg.org > Subject: [tdwg-tapir] ideas & TapirLite > > Hi, > talking to Anton today we were wondering if it makes sense to allow a > tapir client to embed its own request-id into the tapir headers for > later identification of asynchronous and distributed messages. > Currently we would need to identify a message by its sendtime (vague) and source. > > Does this make sense? Does anyone know how other people deal with this > problem? > > ----------- > > The other thoughts were about TapirLite. > We both think its a very bad idea to push all responsibility to the > client by allowing any TAPIR service to be very minimalistic. If a > client should be able to contact services that have different > operators, operations and concepts, then I dont think we will get anything interoperable. > > I still prefer that these things must exist in the most basic TAPIR service. > Otherwise we should call it different - maybe even TAPIR Lite as a > valid > subset: > - all operations > - all logical operators > - the main COPs (<=> like) > > Cconcepts and response models can be optional without much problems I think. > What do you think? should we sacrifice all this to have few clients > but many providers? > > BTW, I think we didnt specify anywhere in capabilities if GET or XML > Messaging is supported. So the idea is to always have both for all > services, right? > > > Markus > > > _______________________________________________ > tdwg-tapir mailing list > tdwg-tapir(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org > > > > _______________________________________________ > 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 -------------------------------------

4 4

Re: RDF/architecture/ontology - migration
by Chuck Miller 21 Nov '05

21 Nov '05

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

Re: RDF/architecture/ontology - migration
by Matt Jones 21 Nov '05

21 Nov '05

Chuck, I believe that the resolution protocol needs to be established or the identifier scheme will not persist. In the SGML days, many people promulgated the use of Formal Public Identifiers (FPI), which can still be seen in use in the DOCTYPE declaration of HTML documents and the like. FPIs defined a syntax for the identifier, but did not specify a resolution mechanism. Rather it left resolution loose so that the identifiers would not become stale. Eventually a catalog system for resolution evolved that was in fairly common use (and was popularized with XCatalog), but I think FPIs ultimately have not worked out precisely because the resolution mechanism was not mandated in the specification. One of the reasons I like LSIDs is that the specification both leaves the resolution mechanism open, saying that several protocols might be used and it might evolve, while at the same time fixing the current resolution protocol to use DNS as its base for finding a resolver. Using SRV records still permits the indirection that is needed for the indetifiers to persist indefinitely. Providing a concrete resolution protocol based on open internet standards allows an interoperable system to quickly materialize. And allowing for future additions and changes to the resolution protocol lends some degree of future-proofing the identifiers. All in all I think it is a reasonable balance where there are several conflicting requirements. Matt Chuck Miller wrote: > 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 > ------------------------------------- > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Matt Jones jones(a)nceas.ucsb.edu National Center for Ecological Analysis and Synthesis (NCEAS) UC Santa Barbara http://www.nceas.ucsb.edu/ecoinformatics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

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

18 Nov '05

Roger, dont get me wrong. I do like the tapir lite idea cause some easy way will be needed. on the other hand I am concerned about becoming too flexible. why do we want tapir at all and why shouldnt we build everything on top of just http calls? The great advantage of a tapir service (so is biocase and digir) is that you can construct your own queries. we could surely build all our system on "simple" webservices, but we would have to define the valid set of them, your API. And this will change over time as we cant think of all questions people want to ask in the future. Another reason is to provide data providers with ready to use software so that they dont have to programm anything themselves. thats why we shouldnt really need a tapir wizard for .net To my point the only reason for having separate non tapir services for TCS is the performance on "complex" databases. But I am not sure even about that. I guess IPNI will not grant their services direct access to their master db but use a copy instead. So they can denormalize things and bring the published db already closer to TCS via views for example. That does cost time, but definetely not as much as writing your own service which has to be maintained and updated. You were asking earlier about use cases and statistics about digir/biocase queries today. I am not sure about that, but I guess there will be mainly portals and indexing queries accessing our providers. Very simple things we can actually easily emulate with get webservices. So should we maybe get rid of tapir at all? or just have one big instance in front of the gbif cache? then why not issue direct sql statements cause we know the schema of that db? These are all questions that came to my mind over the past days, but I dont really wanna suggest anything yet. But coming back to your 3 ways of dealing with tapir lite, my current favorite is full tapir services + wsdl soap services. what is a capability response good for that only tells me I dont understand you? It starts snowing here in Berlin... Markus -----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Roger Hyam Gesendet: Freitag, 18. November 2005 13:35 An: Döring, Markus Cc: tdwg-tapir(a)lists.tdwg.org Betreff: Re: [tdwg-tapir] ideas & TapirLite Hi Markus, The original motivations behind TapirLite was a reaction to the custom response model (which seemed very difficult to implement) and the perceived need for a simple web service like system that could be implemented in a simple way on top of complex 'legacy' systems. The fact that the custom response models are now formally on more of an experimental footing has removed 50% of the motivation but the simple service motivation remains. You are correct in that TapirLite isn't really Tapir at all. It IS just a GET based web service. The kind of thing that full Tapir implementations would have no problem in imitating. Currently (well some of the time) I am trying to figure out a simple API for taxonomic data source that will enable people like Donald to crawl them in something of a meaningful way. I can't assume that data providers will be happy to install (or write) a full Tapir implementation (what if you are in a .Net only environment etc). They have their own agendas and the simpler the system they have to put in place the more likely they are to do it. My hope was to keep them within the Tapir fold. So options are: 1. Define the API in terms of simple http calls. Data providers can either write their own script or they can get a full Tapir provider to imitate the taxonomic API. Advantage is it might actually be quick and easy both to define and implement. Disadvantage is it doesn't integrate with other Tapir providers in the long run - no metadata or capabilities responses. 2. Define the API in terms of templated Tapir calls and insure that any script that is written makes the data provider look like a very limited Tapir provider (the TapirLite approach). Advantage is that it provides consistent metadata and other calls in line with other Tapir providers. Disadvantage is that it actually adds complexity to the Tapir protocol by having too many things optional and adds complexity to the custom scripts. 3. Use another technology altogether such as SOAP or XML-RPC to expose the API. Advantage is that organisation and individuals involved are familiar with the technologies, easier to hire and outsource etc (VisualStudio doesn't yet provide a Tapir integration wizard!). Disadvantage is that it doesn't integrate with Tapir. As I write this all three approaches look equally attractive so I am not advocating anything just rolling ideas around. I'd be grateful for any thoughts that help clarify this. If it would mean getting Tapir to version 1 quicker if option 2 above was dropped then it might be a good strategy. I assume Tapir's primary function is to unite DiGIR and BioCASE and the notion of TapirLite probably should not get in the way of this. Roger Döring, Markus wrote: I would like to get into the lite idea a bit more in detail. Lets start with the list of expected "levels" of tapir compliant services: 1- a full TAPIR service incl an experimental dynamic custom output model 2- a full TAPIR service restricted to certain output models identfied via a list of URLs pointing to the output model definition documents 3- a TAPIR Lite that only wants to accept certain parameters for fixed queries. The main idea as I can see is to have a limited list (maybe only 1?) of query templates here (reminder: QTs are filters & a URL reference to an output model) that define the accepted parameters. I assume this service also only works via http GET and not through xml messaging. The difference between level 1 & 2 is quite small (not necessarily for implementations though). The list of accepted output models simply go into the capabilities of a provider and a client can easily identfy if it is able to communicate with a datasource service. A level 3 TAPIR lite service is quite different from the others. Essentially its a regular GET based webservice that can be described by a WSDL, cause no serialised filter is allowed and the response model is fixed. If we really want to define these kind of simple services with the same protocol schema, what should be its "capabilities"? - only http GET invocation, no xml messaging - the TAPIR envelope should be supported for responses - ping, metadata, capabilites should work - no inventory operation - no (complex) filters or variables, only parameters If only parameters are accepted, then this is not a real search. In the old protocol this was a distinct "view" operation. What we want here is exactly this again. A service only available via http get and parameters. A list of accepted query templates would be enough and no operators, variables and alike need to be supported. The current definition of capabilities does only allow to specify http-GET only services or the accepted list of query templates by the way! A new adhoc idea: what about defining these 3 levels and allowing no other intermediate compliance? Then we can reduce the capabilities a lot, a lot of burden would be removed from clients and we would get more interoperability? Just a quick thought when looking at the above. We could make it as simple as this: <FullService accept_custom_models="false"> <supportedModels> <model location="URI" namespace=""> ... </supportedModels> <concepts> <concept id="..." /> ... </concepts> </FullService> or <LiteService> <supportedQueryTemplates> <template location="URI"> <parameter name="" /> ... </template> ... </supportedQueryTemplates> </LiteService> What do you think? I am really a bit afraid of ending up with different services that implement only bits of the specification. We are about to move all burden towards the clients which for my feeling should be easy to create as a researcher with just simple programming knowledge. Sorry to raise this issue again and especially for this drastic new suggestion. It came up while writing this mail, so dont take it for a well thought idea. I just want to think a bit more about the problems involved in having variable and mutating tapir services. Markus -----Ursprüngliche Nachricht----- Von: Roger Hyam [mailto:roger@tdwg.org] Gesendet: Freitag, 18. November 2005 10:32 An: Donald Hobern Cc: Döring, Markus; tdwg-tapir(a)lists.tdwg.org Betreff: Re: [tdwg-tapir] ideas & TapirLite As TapirLite champion I do have a problem with having to implement all the operators. I just want to be pretty and dumb! I don't have a problem with the concept of a named subset protocol i.e. Tapir (the real thing) and TapirLite (the not so bright second cousin). Are there some use cases somewhere listing what Tapir clients are expected to call or some statistical break down of what kinds of queries are run against existing BioCASE and DiGIR providers? Roger Donald Hobern wrote: Markus, Doesn't "all operations" imply that the provider must implement generic search operations? Isn't a large part of the reason for TAPIR Lite the need to support "databases" that cannot be mapped using the standard RDBMS mapping and which are just trying to emulate common views? I would say that these should be supported but that each TDWG content subgroup needs to define a set of (web service) interfaces that must be supported by any compliant provider. If they can handle this set of views, they may appear as TAPIR providers. Or did I miss something? 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 "Döring, Markus" Sent: 17 November 2005 16:25 To: tdwg-tapir(a)lists.tdwg.org Subject: [tdwg-tapir] ideas & TapirLite Hi, talking to Anton today we were wondering if it makes sense to allow a tapir client to embed its own request-id into the tapir headers for later identification of asynchronous and distributed messages. Currently we would need to identify a message by its sendtime (vague) and source. Does this make sense? Does anyone know how other people deal with this problem? ----------- The other thoughts were about TapirLite. We both think its a very bad idea to push all responsibility to the client by allowing any TAPIR service to be very minimalistic. If a client should be able to contact services that have different operators, operations and concepts, then I dont think we will get anything interoperable. I still prefer that these things must exist in the most basic TAPIR service. Otherwise we should call it different - maybe even TAPIR Lite as a valid subset: - all operations - all logical operators - the main COPs (<=> like) Cconcepts and response models can be optional without much problems I think. What do you think? should we sacrifice all this to have few clients but many providers? BTW, I think we didnt specify anywhere in capabilities if GET or XML Messaging is supported. So the idea is to always have both for all services, right? Markus _______________________________________________ tdwg-tapir mailing list tdwg-tapir(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org _______________________________________________ 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 -------------------------------------

3 2

RDF/architecture/ontology - migration
by Roger Hyam 18 Nov '05

18 Nov '05

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

Re: [tdwg-tapir] search with no result
by "Döring, Markus" 18 Nov '05

18 Nov '05

OK, agreed. Gonna put it to the wiki notes until we get the specs sorted: http://ww3.bgbm.org/protocolwiki/PreliminaryProtocolNotes markus -----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Roger Hyam Gesendet: Freitag, 18. November 2005 10:33 An: Steven Perry Cc: tdwg-tapir(a)lists.tdwg.org Betreff: Re: [tdwg-tapir] search with no result A blank (as in just XML declaration) sounds good to me. Roger Steven Perry wrote: Markus, I've been wondering about this too. My feeling is that we simply return an empty document (xml definition at top, but empty otherwise). I think defining a custom <NULL> or <NoMatches> element may be confusing because with no envelope, the message should be an instance of some schema other than TAPIR -- one that does not define <NULL> or <NoMatches>. I think the first approach (empty doc) is less likely to break clients. -Steve Döring, Markus wrote: I found an unsolved problem in my pywrapper notes today regarding envelope-less operations. If I request a TAPIR GET service search operation which doesnt match any results, what should be returned? Without an envelope this would be an empty document without even a root! Should we turn on the envelope in this case? Or return something like <NULL> or <NoMatches> defined by the protocol? Markus _______________________________________________ tdwg-tapir mailing list tdwg-tapir(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org _______________________________________________ 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 -------------------------------------

1 0