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

> 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?

Hi Scott,
  Fun! There's undoubtedly a number of ways that this can be done, but we (e.g. for Bio2RDF and SADI projects) would do it as follows using the Semanticscience Integrated Ontology (SIO):  

http://semanticscience.org/ontology/sio.owl


Simplified using (dash for space) labels and : for entities in the local namespace...

1)
:radiology-report rdf:type sio:document
:radiology-report sio:contains :mammogram
:mammogram rdf:type sio:image
:mammogram sio:describes :microcalcification 
:microcalcification rdf:type SNOMED:12747003

2)
:mammogram sio:has-component-part :region
:region rdf:type sio:site
:region sio:created-by :software-program  # another relation, such as identified-by may be necessary here
:software-program rdf:type sio:software-application
:region sio:represents :microcalcification
:region sio:has-attribute :feature-identification-confidence
:feature-identification-confidence rdf:type sio:quantity
:feature-identification-confidence sio:has-value "90"
:feature-identification-confidence sio:has-unit unit:percent_unit

3)
:region sio:has-boundary sio:polyline
:polyline sio:has-component-part sio:line-segment
:line-segment sio:has-component-part :start-point
:line-segment sio:has-component-part :end-point
:start-point sio:has-location :x-coordinate-1
:start-point sio:has-location :y-coordinate-1
:x-coordinate-1 rdf:type sio:x-cartesian-coordinate
:y-coordinate-1 rdf:type sio:y-cartesian-coordinate
:x-coordinate-1 sio:has-value "x1 "
:y-coordinate-1 sio:has-value "y1 "
:end-point sio:has-location :x-coordinate-2
:end-point sio:has-location :y-coordinate-2
:x-coordinate-2 rdf:type sio:x-cartesian-coordinate
:y-coordinate-2 rdf:type sio:y-cartesian-coordinate
:x-coordinate-2 sio:has-value "x2 "
:y-coordinate-2 sio:has-value "y2 "

While the coordinate data is verbose, it is quite extensible (one can annotate the points with other information such as colours or values, and we can use different position systems e.g. polar coordinates. This representation is in line with that used in our molecular surface project, which implements a SADI service interface http://semanticscience.org/projects/mosumo/index.html


Cheers!

m.
 
> 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 17:39:22 UTC