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