TAG Roadmap for 2008 - Job vacancy!
Dear TAG Member, With kind support from others I have now pulled together what I believe is the text for the 2008 Roadmap. I will polish this some more but do not plan to change it radically. This will be presented to the conference in Fremantle next month as the output of the TAG. http://wiki.tdwg.org/twiki/bin/view/TAG/RoadMap2008 Please take a few moments to read this through and edit or comment on the list if you don't agree with it or think anything is missing. I will take silence as assent! On or around the 8th October I will convert the wiki page into a PDF and start distributing it. I would like to take this opportunity to announce that I wish to stand down as convener of the TAG as of the Fremantle conference. I believe it would be good for the TAG and TDWG to have some fresh blood in this position. I still hope to continue contributing to TDWG but perhaps in different ways. The procedure for choosing a new convener is somewhat vague but I believe it should be done through group consensus. Perhaps we could start a discussion on this list and those who are coming to Fremantle could discuss it further. Who do you think should take this forward? Would you like to take this forward? All the best, Roger ------------------------------------------------------------- Roger Hyam Roger@BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org ------------------------------------------------------------- Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/ -------------------------------------------------------------
Just a thought... REST based services seem to be gaining a lot of momentum lately, so I wonder if we should mention them in the RoadMap ?? I would at least like to bring up the subject at some point during the TDWG meeting, and look at how REST may fit in with LSIDs, etc. Kevin
Roger Hyam <rogerhyam@mac.com> 30/09/2008 11:02 p.m. >>>
Dear TAG Member, With kind support from others I have now pulled together what I believe is the text for the 2008 Roadmap. I will polish this some more but do not plan to change it radically. This will be presented to the conference in Fremantle next month as the output of the TAG. http://wiki.tdwg.org/twiki/bin/view/TAG/RoadMap2008 Please take a few moments to read this through and edit or comment on the list if you don't agree with it or think anything is missing. I will take silence as assent! On or around the 8th October I will convert the wiki page into a PDF and start distributing it. I would like to take this opportunity to announce that I wish to stand down as convener of the TAG as of the Fremantle conference. I believe it would be good for the TAG and TDWG to have some fresh blood in this position. I still hope to continue contributing to TDWG but perhaps in different ways. The procedure for choosing a new convener is somewhat vague but I believe it should be done through group consensus. Perhaps we could start a discussion on this list and those who are coming to Fremantle could discuss it further. Who do you think should take this forward? Would you like to take this forward? All the best, Roger ------------------------------------------------------------- Roger Hyam Roger@BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org ( http://www.BiodiversityCollectionsIndex.org/ ) ------------------------------------------------------------- Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/ ------------------------------------------------------------- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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. http://www.landcareresearch.co.nz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Yes, I agree REST seems a lot easier to implement, and at least having some information on how REST fits in would be helpful. Cheers, Ben -----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org]On Behalf Of Kevin Richards Sent: Friday, 3 October 2008 6:29 To: Technical Architecture Group mailing list; Roger Hyam Subject: Re: [tdwg-tag] TAG Roadmap for 2008 - Job vacancy! Just a thought... REST based services seem to be gaining a lot of momentum lately, so I wonder if we should mention them in the RoadMap ?? I would at least like to bring up the subject at some point during the TDWG meeting, and look at how REST may fit in with LSIDs, etc. Kevin
Roger Hyam <rogerhyam@mac.com> 30/09/2008 11:02 p.m. >>>
Dear TAG Member, With kind support from others I have now pulled together what I believe is the text for the 2008 Roadmap. I will polish this some more but do not plan to change it radically. This will be presented to the conference in Fremantle next month as the output of the TAG. http://wiki.tdwg.org/twiki/bin/view/TAG/RoadMap2008 Please take a few moments to read this through and edit or comment on the list if you don't agree with it or think anything is missing. I will take silence as assent! On or around the 8th October I will convert the wiki page into a PDF and start distributing it. I would like to take this opportunity to announce that I wish to stand down as convener of the TAG as of the Fremantle conference. I believe it would be good for the TAG and TDWG to have some fresh blood in this position. I still hope to continue contributing to TDWG but perhaps in different ways. The procedure for choosing a new convener is somewhat vague but I believe it should be done through group consensus. Perhaps we could start a discussion on this list and those who are coming to Fremantle could discuss it further. Who do you think should take this forward? Would you like to take this forward? All the best, Roger ------------------------------------------------------------- Roger Hyam Roger@BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org <http://www.BiodiversityCollectionsIndex.org/> ------------------------------------------------------------- Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/ ------------------------------------------------------------- Please consider the environment before printing this email 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. <http://www.landcareresearch.co.nz> http://www.landcareresearch.co.nz This email, together with any attachments, is intended for the addressee only. It may contain confidential or privileged information. If you are not the intended recipient of this email, please notify the sender, delete the email and attachments from your system and destroy any copies you may have taken of the email and its attachments. Duplication or further distribution by hardcopy, by electronic means or verbally is not permitted without permission.
Yes I think you are right a REST section would be good but.... What is REST? In a way the TAPIR specification (especially in its lighter versions) is 'just' a common REST specification. You pass it parameters over HTTP and you get back data as XML. On the other hand TAPIR seems more complex than just putting a REST service together. Perhaps because doing anything that meets a specification rather than just what comes to hand is going to be harder. Perhaps Renato may have comments on this. I have actually just done a REST/JSON service for BCI. http://biocol.org/json I am nervous because it is totally not TDWG standards compliant and just a useful thing for getting data back for mashups and embedding. Effectively exposing the database to client side applications. From an engineering point of view it is dead simple - a single PHP file (within the Zend Framework). To write code to consume this is trivial (there is an example) but it is bespoke. a major thing is that the return type is JSON which I think many people think of a standard data format for REST type services. So it would be a good to get some clarification on what we mean by REST. Does REST tend to imply a particular return type? If we mean REST/JSON does anyone have an idea how we could get some data typing in a JSON object so that a consuming application could tell that it is a representation of a DwC object or something from the TDWG ontology? Service description is also an issue. We end up re- inventing TAPIR if we aren't careful. I am sure it would be trivial to wrap a TAPIR provider in something that converted the XML output to JSON enabling it to act as a data source for client mashups. As usual I'd be grateful for opinions on this. Perhaps we should talk in Fremantle. All the best, Roger On 3 Oct 2008, at 02:56, Richardson, Ben wrote:
Yes, I agree
REST seems a lot easier to implement, and at least having some information on how REST fits in would be helpful.
Cheers, Ben -----Original Message----- From: tdwg-tag-bounces@lists.tdwg.org [mailto:tdwg-tag-bounces@lists.tdwg.org ]On Behalf Of Kevin Richards Sent: Friday, 3 October 2008 6:29 To: Technical Architecture Group mailing list; Roger Hyam Subject: Re: [tdwg-tag] TAG Roadmap for 2008 - Job vacancy!
Just a thought...
REST based services seem to be gaining a lot of momentum lately, so I wonder if we should mention them in the RoadMap ?? I would at least like to bring up the subject at some point during the TDWG meeting, and look at how REST may fit in with LSIDs, etc.
Kevin
Roger Hyam <rogerhyam@mac.com> 30/09/2008 11:02 p.m. >>>
Dear TAG Member,
With kind support from others I have now pulled together what I believe is the text for the 2008 Roadmap. I will polish this some more but do not plan to change it radically. This will be presented to the conference in Fremantle next month as the output of the TAG.
http://wiki.tdwg.org/twiki/bin/view/TAG/RoadMap2008
Please take a few moments to read this through and edit or comment on the list if you don't agree with it or think anything is missing. I will take silence as assent!
On or around the 8th October I will convert the wiki page into a PDF and start distributing it.
I would like to take this opportunity to announce that I wish to stand down as convener of the TAG as of the Fremantle conference. I believe it would be good for the TAG and TDWG to have some fresh blood in this position. I still hope to continue contributing to TDWG but perhaps in different ways.
The procedure for choosing a new convener is somewhat vague but I believe it should be done through group consensus. Perhaps we could start a discussion on this list and those who are coming to Fremantle could discuss it further.
Who do you think should take this forward? Would you like to take this forward?
All the best,
Roger
------------------------------------------------------------- Roger Hyam Roger@BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org ------------------------------------------------------------- Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/ -------------------------------------------------------------
<IMAGE.jpg> Please consider the environment before printing this email
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. http://www.landcareresearch.co.nz
This email, together with any attachments, is intended for the addressee only. It may contain confidential or privileged information. If you are not the intended recipient of this email, please notify the sender, delete the email and attachments from your system and destroy any copies you may have taken of the email and its attachments. Duplication or further distribution by hardcopy, by electronic means or verbally is not permitted without permission. _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
------------------------------------------------------------- Roger Hyam Roger@BiodiversityCollectionsIndex.org http://www.BiodiversityCollectionsIndex.org ------------------------------------------------------------- Royal Botanic Garden Edinburgh 20A Inverleith Row, Edinburgh, EH3 5LR, UK Tel: +44 131 552 7171 ext 3015 Fax: +44 131 248 2901 http://www.rbge.org.uk/ -------------------------------------------------------------
Good question. It's also not easy for me to draw a line between RESTful and RESTless services. Although TAPIR is based on operations, which could be seen as something closer to an RPC approach, it has just a few quite generic operations. On the other hand, for sure TAPIR offers simple ways to interact with the service and to easily expose URLs for any underlying resource (using the term "resource" here in the general sense). REST junkies can even configure re-write rules very easily on a web server to allow "cleaner" URLs for resources that are exposed through a TAPIR service. I don't think TAPIR is harder just because you need to follow a specification - this could actually make things easier, obviously depending on the complexity of the specification. Remember that TAPIR was created to be used by distributed data providers who want to share the same kind of data using the same protocol, so there's all that additional stuff related with data abstraction, conceptual schemas, etc. The BCI service seems to be built on top of a central database in a single data provider scenario (or am I wrong?) so it's understandable not to use TAPIR. I think it was Wouter who found some time ago a generic XSLT to convert any XML to JSON. I never used it and I'm not sure if I still have a copy somewhere. A first step towards standardizing JSON representations for our objects could be to play with this kind of generic stylesheet to convert TDWG ontolgy objects represented in RDF/XML to JSON. Best Regards, -- Renato
Yes I think you are right a REST section would be good but.... What is REST? In a way the TAPIR specification (especially in its lighter versions) is 'just' a common REST specification. You pass it parameters over HTTP and you get back data as XML. On the other hand TAPIR seems more complex than just putting a REST service together. Perhaps because doing anything that meets a specification rather than just what comes to hand is going to be harder. Perhaps Renato may have comments on this.
I have actually just done a REST/JSON service for BCI.
I am nervous because it is totally not TDWG standards compliant and just a useful thing for getting data back for mashups and embedding. Effectively exposing the database to client side applications. From an engineering point of view it is dead simple - a single PHP file (within the Zend Framework). To write code to consume this is trivial (there is an example) but it is bespoke. a major thing is that the return type is JSON which I think many people think of a standard data format for REST type services.
So it would be a good to get some clarification on what we mean by REST.
Does REST tend to imply a particular return type?
If we mean REST/JSON does anyone have an idea how we could get some data typing in a JSON object so that a consuming application could tell that it is a representation of a DwC object or something from the TDWG ontology? Service description is also an issue. We end up re- inventing TAPIR if we aren't careful.
I am sure it would be trivial to wrap a TAPIR provider in something that converted the XML output to JSON enabling it to act as a data source for client mashups.
As usual I'd be grateful for opinions on this. Perhaps we should talk in Fremantle.
All the best,
Roger
There seem to be several mechanisms around to serialize RDF in JSON, e.g. http://n2.talis.com/wiki/RDF_JSON_Specification and http://www.gbv.de/wikis/cls/RDF_in_JSON which may actually produce the same JSON Also, see http://www.w3.org/TR/rdf-sparql-json-res/ --Bob On Fri, Oct 3, 2008 at 3:41 PM, Renato De Giovanni <renato@cria.org.br> wrote:
... I think it was Wouter who found some time ago a generic XSLT to convert any XML to JSON. I never used it and I'm not sure if I still have a copy somewhere. A first step towards standardizing JSON representations for our objects could be to play with this kind of generic stylesheet to convert TDWG ontolgy objects represented in RDF/XML to JSON.
Best Regards, -- Renato
Yes I think you are right a REST section would be good but.... What is REST? In a way the TAPIR specification (especially in its lighter versions) is 'just' a common REST specification. You pass it parameters over HTTP and you get back data as XML. On the other hand TAPIR seems more complex than just putting a REST service together. Perhaps because doing anything that meets a specification rather than just what comes to hand is going to be harder. Perhaps Renato may have comments on this.
I have actually just done a REST/JSON service for BCI.
I am nervous because it is totally not TDWG standards compliant and just a useful thing for getting data back for mashups and embedding. Effectively exposing the database to client side applications. From an engineering point of view it is dead simple - a single PHP file (within the Zend Framework). To write code to consume this is trivial (there is an example) but it is bespoke. a major thing is that the return type is JSON which I think many people think of a standard data format for REST type services.
So it would be a good to get some clarification on what we mean by REST.
Does REST tend to imply a particular return type?
If we mean REST/JSON does anyone have an idea how we could get some data typing in a JSON object so that a consuming application could tell that it is a representation of a DwC object or something from the TDWG ontology? Service description is also an issue. We end up re- inventing TAPIR if we aren't careful.
I am sure it would be trivial to wrap a TAPIR provider in something that converted the XML output to JSON enabling it to act as a data source for client mashups.
As usual I'd be grateful for opinions on this. Perhaps we should talk in Fremantle.
All the best,
Roger
_______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
-- Robert A. Morris Professor of Computer Science UMASS-Boston ram@cs.umb.edu http://bdei.cs.umb.edu/ http://www.cs.umb.edu/~ram http://www.cs.umb.edu/~ram/calendar.html phone (+1)617 287 6466
Perhaps I missed this, but what is the requirement driving serialization of RDF or XML in JSON? Adoption of REST strategies does not require or even imply JSON encoding, so is the goal to provide rich content to browsers that is easily parsed by javascript applications? In any case with the variety of formats and tools available for serializing RDF it is trivial (assuming that the XML, RDF/XML, or whatever is being produced on the fly) to support agent-driven content negotiation and have the web server respond with appropriately serialized content based on the mime type indicated in the HTTP Accept header forwarded by the client (json = application/json, rdfxml = application/rdf+xml). I guess one could also request text/csv if semantics weren't of interest. Dave V. On Oct 3, 2008, at 14:39 , Bob Morris wrote:
There seem to be several mechanisms around to serialize RDF in JSON, e.g. http://n2.talis.com/wiki/RDF_JSON_Specification and http://www.gbv.de/wikis/cls/RDF_in_JSON
which may actually produce the same JSON
Also, see http://www.w3.org/TR/rdf-sparql-json-res/
--Bob
On Fri, Oct 3, 2008 at 3:41 PM, Renato De Giovanni <renato@cria.org.br> wrote:
... I think it was Wouter who found some time ago a generic XSLT to convert any XML to JSON. I never used it and I'm not sure if I still have a copy somewhere. A first step towards standardizing JSON representations for our objects could be to play with this kind of generic stylesheet to convert TDWG ontolgy objects represented in RDF/XML to JSON.
Best Regards, -- Renato
Yes I think you are right a REST section would be good but.... What is REST? In a way the TAPIR specification (especially in its lighter versions) is 'just' a common REST specification. You pass it parameters over HTTP and you get back data as XML. On the other hand TAPIR seems more complex than just putting a REST service together. Perhaps because doing anything that meets a specification rather than just what comes to hand is going to be harder. Perhaps Renato may have comments on this.
I have actually just done a REST/JSON service for BCI.
I am nervous because it is totally not TDWG standards compliant and just a useful thing for getting data back for mashups and embedding. Effectively exposing the database to client side applications. From an engineering point of view it is dead simple - a single PHP file (within the Zend Framework). To write code to consume this is trivial (there is an example) but it is bespoke. a major thing is that the return type is JSON which I think many people think of a standard data format for REST type services.
So it would be a good to get some clarification on what we mean by REST.
Does REST tend to imply a particular return type?
If we mean REST/JSON does anyone have an idea how we could get some data typing in a JSON object so that a consuming application could tell that it is a representation of a DwC object or something from the TDWG ontology? Service description is also an issue. We end up re- inventing TAPIR if we aren't careful.
I am sure it would be trivial to wrap a TAPIR provider in something that converted the XML output to JSON enabling it to act as a data source for client mashups.
As usual I'd be grateful for opinions on this. Perhaps we should talk in Fremantle.
All the best,
Roger
_______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
-- Robert A. Morris Professor of Computer Science UMASS-Boston ram@cs.umb.edu http://bdei.cs.umb.edu/ http://www.cs.umb.edu/~ram http://www.cs.umb.edu/~ram/calendar.html phone (+1)617 287 6466 _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
participants (6)
-
Bob Morris -
Dave Vieglais -
Kevin Richards -
Renato De Giovanni -
Richardson, Ben -
Roger Hyam