RE: best practice relation for linking to image/machine-opaque docs? biomedical use case

hi tim and scott,

in looking at the ImageSelector, i'm surprised there are no units
specifically specified, either as a default or as a property.  are they
assumed to be pixels?

also, you might want to take a look at GelML
(http://psidev.info/index.php?q=node/448) for a bit more sophisticated way
to specify a position.  the specification allows four different types of
basic shapes: BoundaryChain, BoundaryPointSet, Circle, and Rectangle.
altho it's an XML Schema spec, it should be easy enough to translate to
RDF.

cheers,
michael


> -----Original Message-----
> From: public-semweb-lifesci-request@w3.org [mailto:public-semweb-
> lifesci-request@w3.org] On Behalf Of Tim Clark
> Sent: Monday, January 10, 2011 11:35 AM
> To: M. Scott Marshall
> Cc: HCLS IG; public-lod@w3.org; Daniel Rubin; John F. Madden; Vasiliy
> Faronov; Toby Inkster; Peter DeVries; Tim Berners-Lee; Paolo Ciccarese;
> Anita de Waard; Maryann Martone
> Subject: Re: best practice relation for linking to image/machine-opaque
> docs? biomedical use case
>
> Hi Scott,
>
> For referring to a portion of an image, let me point you to work in my
> group done in collaboration with HCLS Scientific Discourse Task, UCSD,
> Elsevier, and one of the major pharmas.  Paolo Ciccarese is the main
> author, and this work is based on the earlier W3C project Annotea.
>
> AO, Annotation ontology, here: http://code.google.com/p/annotation-
> ontology/, presented at Bio Ontologies 2010, and full-length paper in
> press at BMC Bioinformatics.
>
> Bio Ontologies 2010 slides here:
> http://www.slideshare.net/paolociccarese/ao-annotation-ontology-for-
> science-on-the-web
>
> AO uses a special subclass of Selector to specify the part of the
> document (image) being referred to.
>
> see here for Selectors: http://code.google.com/p/annotation-
> ontology/wiki/Selectors
>
> and here for an example of image annotation:
> http://code.google.com/p/annotation-ontology/wiki/AnnotationTypes
>
> Best
>
> Tim
>
> On Jan 10, 2011, at 11:30 AM, M. Scott Marshall wrote:
>
> > [Scott dusts off old use case and pulls from the shelf. Adjusts
> > subject of thread. Was: best practice for referring to PDF]
> >
> > In Health Care and Life Science domains, image data is a common form
> > of data under discussion so a best practice for referring to an image
> > or to an (extractable) feature *within* an image would cover a
> > fundamental need in biomedicine to point to 'raw' data as evidence
> (as
> > well as giving meaning to the raw data!).
> >
> > A clinical example from breast cancer:
> > There is a scan that produces an image that contains features
> referred
> > to by the radiologist as 'microcalcifications', which can be
> > indicative of the presence of a tumor.
> >
> > I can think of a few scenarios that would refer to the image data
> > (mammogram). There are probably more:
> > 1) The radiology report (in RDF) asserts the presence of
> > microcalcifications and refers to the entire image as evidence.
> > 2) The radiology report (in RDF) asserts the presence of
> > microcalcifications and refers to the entire image as evidence, along
> > with a image processing/feature extraction program that will
> highlight
> > the phenomenon in the image.
> > 3) The radiology report (in RDF) asserts the presence of
> > microcalcifications and refers to a specific region in the image as
> > evidence using some function of a 2D coordinate system such as
> > polyline.
> >
> > The question: How can we refer to the microcalcifications as an
> > indication of a certain type of tumor in each case 1, 2, and 3 in
> RDF?
> >
> > I am especially interested in the 'structural' aspects: How do we
> > refer to the image document as containingEvidence ? How can we refer
> > to a *region* of the image in the document? How can we refer to the
> > software that will extract the relevant features with statistical
> > confidence, etc.?
> >
> > Any ideas or pointers to existing practices would be appreciated. I'm
> > aware of some related work in multimedia to refer to temporal regions
> > but I am specifically interested in spatial regions.
> >
> > Note that an analogous question of practice exists for textual
> > documents such as literature in PubMed that can be text-mined for
> > (evidence of) assertions.
> >
> > * Note: 2D is a simplification that should come in handy in
> > implementations and often deemed necessary, such as thumbnails.
> >
> > -Scott
> >
> > --
> > M. Scott Marshall, W3C HCLS IG co-chair, http://www.w3.org/blog/hcls
> > Leiden University Medical Center / University of Amsterdam
> > http://staff.science.uva.nl/~marshall
> >
> > On Mon, Jan 10, 2011 at 4:01 PM, Tim Berners-Lee <timbl@w3.org>
> wrote:
> >> It is well to look at and make best practices for the things
> >> we have if we don't
> >>
> >> It was the FOAF folks who, initially, instead of using linked data,
> >> used an Inverse Functional Property to uniquely identify
> >> someone and then rdfs:seeAlso to find the data about them.
> >> So any FOAF browser has to look up the seeAlso  or they
> >> don't follow any links.
> >>
> >> So tabulator always when looking up x and finding x see:also y will
> >> load y.  So must any similar client or any crawler.
> >>
> >> So there is a lot of existing use we would throw away if we
> >> allowed rdfs:seeAlso for pointing to things which do not
> >> provide data. (It isn't the question of conneg or mime type,
> >> that is a red herring. it is whether there is machine-redable
> >> standards-based stuff about x).
> >>
> >> Further, we should not make any weaker properties like
> seeDocumentation
> >> subproperties of see:Also, or they would imply
> >> We maybe need a very weak top property like
> >>
> >> mayHaveSomeKindOfInfoAboutThis
> >>
> >> to be the superProperty of all the others.
> >>
> >> One things which could be stronger than seeAlso is definedBy if it
> >> is normally used for data, to point to the definitive ontology.
> >> That would then imply seeAlso.
> >>
> >> Tim
> >
> >
>

Received on Monday, 10 January 2011 20:28:50 UTC