- From: Michael Miller <mmiller@systemsbiology.org>
- Date: Mon, 10 Jan 2011 12:28:15 -0800
- To: Tim Clark <tim_clark@harvard.edu>, "M. Scott Marshall" <mscottmarshall@gmail.com>
- Cc: HCLS IG <public-semweb-lifesci@w3.org>, public-lod@w3.org, Daniel Rubin <dlrubin@stanford.edu>, "John F. Madden" <john.madden@duke.edu>, Vasiliy Faronov <vfaronov@gmail.com>, Toby Inkster <tai@g5n.co.uk>, Peter DeVries <pete.devries@gmail.com>, Tim Berners-Lee <timbl@w3.org>, Paolo Ciccarese <paolo.ciccarese@gmail.com>, Anita de Waard <A.dewaard@elsevier.com>, Maryann Martone <maryann@ncmir.ucsd.edu>
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