Hi,
Thanks for adding media content to the occurrence endpoint output. I am curious if the below is the intended behavior. It appears as though the "references" field associated with an array of "type", "format", and "identifier" is in the next array. Does it not make more sense to have the "references" field within the same array so when parsed we can easily tell that they go together? I can tell by seeing that the photo ID is the same, but I wonder if that is the best approach since then we need to make sure a "references" field goes with an arry of type/format/identifier by e.g. regex-ing.
Sorry if I am misunderstanding why this is the way it is :)
[ { type: "StillImage", format: "image/jpeg", identifier: "http://static.inaturalist.org/photos/696339/medium.JPG?1393473140" }, { references: "http://conabio.inaturalist.org/photos/696339" }, { type: "StillImage", format: "image/jpeg", identifier: "http://static.inaturalist.org/photos/696341/medium.JPG?1393473245" }, { references: "http://conabio.inaturalist.org/photos/696341" } ]
Thanks! Scott Chamberlain
Hi Scott, the problem is slightly different from what it appears to be. The array of media items is indeed a list of 4 images. I could not find your example, but you can pick pretty much any of the iNaturalist observations, for example this one here: http://api.gbif.org/v0.9/occurrence/899944100
There are 2 media items, one with a url to the image, one a link to the respective webpage. If you look at the verbatim content you can see that we simply get a list of 2 URLs concatenated into the single dwc:associatedMedia field: http://api.gbif.org/v0.9/occurrence/899944100/verbatim
Why cannot safely know that the 2 links are indeed about the same image, so these end up being to media item. Because one of them has a jpg suffix we know it is a link to the image and derive a file type. This can be avoided by using the richer multimedia extension which allows an image and a webpage link within the same record: http://rs.gbif.org/extension/gbif/1.0/multimedia.xml
See also our blog post which explains this issue in more details: http://gbif.blogspot.de/2014/05/multimedia-in-gbif.html
best, Markus
-- Markus Döring Software Developer Global Biodiversity Information Facility (GBIF) mdoering@gbif.org http://www.gbif.org
On 29 Jun 2014, at 07:59, Scott Chamberlain scott@ropensci.org wrote:
Hi,
Thanks for adding media content to the occurrence endpoint output. I am curious if the below is the intended behavior. It appears as though the "references" field associated with an array of "type", "format", and "identifier" is in the next array. Does it not make more sense to have the "references" field within the same array so when parsed we can easily tell that they go together? I can tell by seeing that the photo ID is the same, but I wonder if that is the best approach since then we need to make sure a "references" field goes with an arry of type/format/identifier by e.g. regex-ing.
Sorry if I am misunderstanding why this is the way it is :)
[ { type: "StillImage", format: "image/jpeg", identifier: "http://static.inaturalist.org/photos/696339/medium.JPG?1393473140" }, { references: "http://conabio.inaturalist.org/photos/696339" }, { type: "StillImage", format: "image/jpeg", identifier: "http://static.inaturalist.org/photos/696341/medium.JPG?1393473245" }, { references: "http://conabio.inaturalist.org/photos/696341" } ]
Thanks! Scott Chamberlain _______________________________________________ API-users mailing list API-users@lists.gbif.org http://lists.gbif.org/mailman/listinfo/api-users
Hi Markus,
Thanks very much for your feedback.
I don't remember the exact call I made, but this one shows the same pattern with media elements:
http://api.gbif.org/v0.9/occurrence/search?mediaType=StillImage
Thanks for the clarification. Okay, I can handle the parsing on my end.
Cheers, Scott
On Sun, Jun 29, 2014 at 2:15 PM, Markus Döring m.doering@mac.com wrote:
Hi Scott, the problem is slightly different from what it appears to be. The array of media items is indeed a list of 4 images. I could not find your example, but you can pick pretty much any of the iNaturalist observations, for example this one here: http://api.gbif.org/v0.9/occurrence/899944100
There are 2 media items, one with a url to the image, one a link to the respective webpage. If you look at the verbatim content you can see that we simply get a list of 2 URLs concatenated into the single dwc:associatedMedia field: http://api.gbif.org/v0.9/occurrence/899944100/verbatim
Why cannot safely know that the 2 links are indeed about the same image, so these end up being to media item. Because one of them has a jpg suffix we know it is a link to the image and derive a file type. This can be avoided by using the richer multimedia extension which allows an image and a webpage link within the same record: http://rs.gbif.org/extension/gbif/1.0/multimedia.xml
See also our blog post which explains this issue in more details: http://gbif.blogspot.de/2014/05/multimedia-in-gbif.html
best, Markus
-- Markus Döring Software Developer Global Biodiversity Information Facility (GBIF) mdoering@gbif.org http://www.gbif.org
On 29 Jun 2014, at 07:59, Scott Chamberlain scott@ropensci.org wrote:
Hi,
Thanks for adding media content to the occurrence endpoint output. I am curious if the below is the intended behavior. It appears as though the "references" field associated with an array of "type", "format", and "identifier" is in the next array. Does it not make more sense to have the "references" field within the same array so when parsed we can easily tell that they go together? I can tell by seeing that the photo ID is the same, but I wonder if that is the best approach since then we need to make sure a "references" field goes with an arry of type/format/identifier by e.g. regex-ing.
Sorry if I am misunderstanding why this is the way it is :)
[ { type: "StillImage", format: "image/jpeg", identifier: "http://static.inaturalist.org/photos/696339/medium.JPG?1393473140" }, { references: "http://conabio.inaturalist.org/photos/696339" }, { type: "StillImage", format: "image/jpeg", identifier: "http://static.inaturalist.org/photos/696341/medium.JPG?1393473245" }, { references: "http://conabio.inaturalist.org/photos/696341" } ]
Thanks! Scott Chamberlain _______________________________________________ API-users mailing list API-users@lists.gbif.org http://lists.gbif.org/mailman/listinfo/api-users
participants (2)
-
Markus Döring
-
Scott Chamberlain