I thoroughly agree with Ricardo - surely this is what any normal user would expect. They would get the technical metadata indicating size, etc. AND information on the significance of the image concerned - potentially referencing ontologies (if for example the image serves as a depiction of a character state), taxon concepts (via LSID), specimen records (via LSID), etc. as well as including a text description of what the image represents.
All of this information should be supported - we need the applicability statements to document how DC and other standards should be used to make this possible.
Thanks,
Donald
Ricardo Scachetti Pereira wrote:
Please see my comments in line below.
Bob Morris wrote:
The problem that nobody will take a position on is this:
Is the metadata on an image file, or on an image?
I don't want to dismiss this as a simple problem. We've been trying to knock it down for a long time now. However, I keep wondering why can't we just include information from both (image and image file) in the metadata by using different predicates in each case. See an example below.
Even---or especially if---you stick to DC, you have a problem about what things are part of a description. If the metadata is about the file, then it is reasonable to express, e.g. that it has 1200x800 pixels, encoded as jpeg but perhaps not that it is a a picture of a flea biting a dog. If the image is being described, the reverse might hold.
Couldn't we say the following about an image?
rdf:RDF <tdwg:Image rdf:about="urn:lsid:example.com:image:1234"> dc:titlePicture of my dog Scratchy</dc:title> dc:subjectA picture of a flea biting my dog.</dc:subject> dc:descriptionA description of a flea biting my dog. You get the idea, but an image is worth a thousand words...</dc:description> dc:identifierurn:lsid:example.com:image:1234</dc:identifier> dc:formatimage/jpeg</dc:format> tdwg:imageDimensions1200x800</tdwg:ImageDimensions> </tdwg:Image> </rdf:RDF>
Even though I bet the RDF isn't valid, I hope you get the point that each predicate refers to either the file or the image, but not both.
If some of these predicates aren't suitable, we can always use some other vocabularies (EXIF?). If you want to refer to what's in the picture, we can somehow point to our familiar biodiversity information objects: taxon name, observation, specimen, etc.
Is there a case where this can't be done?
... rendering clients probably desperately need the pixel size and also information about where to find other sizes of the "same" image.
That's a different problem. We had agreed that LSIDs can't be used if the number of representations of an image is infinite or just very large. Should we be looking at OpenURL or just Web services (and WSDL)?? But that's a little advanced for our simple discussion thread, isn't it?
So, is this a feasible solution, or is there a class of counter examples that I'm missing completely?
Cheers,
Ricardo
tdwg-guid mailing list tdwg-guid@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-guid