[tdwg-guid] Need for citation information in GUID metadata

Bob Morris morris.bob at gmail.com
Wed Nov 7 17:08:52 CET 2007


That is basically what Rich Pyle and I argue for at
http://wiki.tdwg.org/twiki/bin/view/Image/ImageOrImageFile, derived
and expanded from his posting here.

There I ask rhetorically whether you have established any semantics
for the relationship between the image and files that are asserted to
represent it. If not, I am willing to have a go at proposing such. As
others have observed, this is not only about media files but about
anything that needs to support discovery, identity, and discourse
about "abstract" things and digital representations of them. It is
just that it is easy and probably uncontroversial to identify and
address some common issues for currently encoded media. (But even in
that case there are some interesting issues to consider. What exactly
is a plastic skull of a T. rex rendered from a mold produced by a 3D
printer from an XRay CAT scan of a T. rex skull dug up from the
ground? Is it like an image file? Is the mold like an image file? Is
either of them like the "ink on paper" type that Paul wishes(?) were
codified? )

[Ironically, in this context, by "abstract" we almost always mean
"concrete" in the conversational sense, whereas the digital
representations are pretty abstract to most people. ]

Bob


On Nov 7, 2007 10:16 AM, Roger Hyam <roger at tdwg.org> wrote:
> My thought is that the LSID should apply to the image (not the file)
> If you want to say something about the file that is separate from the
> image (it's size) you can either refer to it by a plain old URL type
> URI - because it could be just a dynamically generated thing - or
> issue an LSID for the file itself - if you want to archive it and it
> would be useful.
>
> The LSID should be a hook on which services (different renderings)
> are hung.
>
> I actually created a class called DigitalImage
>
> http://rs.tdwg.org/ontology/voc/DigitalImage
>
> in the vocabulary. I don't believe it is used by anyone and it (or
> me) should be taken out and shot as it clearly goes against what I
> say above by including 'Digital'. The class should be able to
> represent an image for which we don't have a digital representation
> at all.
>
> Roger
>
>
>
>
> On 7 Nov 2007, at 09:39, Donald Hobern wrote:
>
> > 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:title>Picture of my dog Scratchy</dc:title>
> >>       <dc:subject>A picture of a flea biting my dog.</dc:subject>
> >>       <dc:description>A description of a flea biting my dog. You
> >> get the idea, but an image is worth a thousand words...</
> >> dc:description>
> >>       <dc:identifier>urn:lsid:example.com:image:1234</dc:identifier>
> >>       <dc:format>image/jpeg</dc:format>
> >>       <tdwg:imageDimensions>1200x800</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 at lists.tdwg.org
> >> http://lists.tdwg.org/mailman/listinfo/tdwg-guid
> >>
> >>
> >
> > --
> > ------------------------------------------------------------
> > Donald Hobern (dhobern at gbif.org)
> > Deputy Director for Informatics Global Biodiversity Information
> > Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen,
> > Denmark
> > Tel: +45-35321483   Mobile: +45-28751483   Fax: +45-35321480
> > ------------------------------------------------------------
> >
> > _______________________________________________
> > tdwg-guid mailing list
> > tdwg-guid at lists.tdwg.org
> > http://lists.tdwg.org/mailman/listinfo/tdwg-guid
>
> _______________________________________________
> tdwg-guid mailing list
> tdwg-guid at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-guid
>



-- 
Robert A. Morris
Professor of Computer Science
UMASS-Boston
ram at 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



More information about the tdwg-tag mailing list