Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
I'd be happy enough to see greater granularity for rdfs:seeAlso. I have a use case where I want to say something like the uri has been minted recently by a source that is not authoritative but that, if widely adopted, could become so. Either way, it's worth noting that he and I are talking about the same thing - and rdfs:seeAlso doesn't really cover that nuance! However... a property should not imply any content type AFAIAC. That's the job of the HTTP Headers. If software de-references an rdfs:seeAlso object and only expects RDF then it should have a suitable accept header. if the server can't respond with that content type, there are codes to handle that. Phil. On 09/01/2011 15:21, Vasiliy Faronov wrote: On Птн, 2011-01-07 at 11:47 -0500, Tim Berners-Lee wrote: Certainly. the tabulator follows rdfs:seeAlso and expects some terse RDF. and so would be crippled by any large file, and PDF would not of course help it at all. I take seeAlso as a fairly strong request to see the other thing, like an HTTP redirect. Not a generic this is vaguely related link at all, and not in general to point to human-readable stuff. Maybe it's time to define several specializations of rdfs:seeAlso with stronger semantics? For example (in a hypothetical namespace): - see:authoritative -- strong pointer to a defining document, equivalent to (or even superseding) follow-your-nose. Could probably just reuse wrds:describedby, though it's not a subproperty of rdfs:seeAlso. - see:continued -- pointer to more data of the same nature. Would be useful for paged data. When you have a blog marked up with RDFa, you may want to let the consumer know that any given page is really just a part of it. Strength depends on the application. - see:historical -- pointer to data that no longer holds, thus cannot be taken at face value, but only in conjunction with some time-related terms (like owlTime:Interval). In other words, don't go there unless you are time-enabled. - see:non_rdf -- pointer to a machine-readable description that is not in a serialization of RDF (GRDDL not counted as one). - see:human_readable -- pointer to a description that is human-readable only. -- Vasiliy Faronov Please consider the environment before printing this email. Find out more about Talis at http://www.talis.com/ shared innovation™ Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete it. Any use of this e-mail by an unauthorised recipient is prohibited. Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB. Talis North America is Talis Inc., 11400 Branch Ct., Fredericksburg, VA 22408, United States of America. -- Phil Archer Talis Systems Ltd, Web: http://www.talis.com Tel: +44 1473 434770 Twitter: philarcher1 LinkedIn: http://uk.linkedin.com/in/philarcher Personal: http://philarcher.org
Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
On Пнд, 2011-01-10 at 08:55 +, Phil Archer wrote: However... a property should not imply any content type AFAIAC. That's the job of the HTTP Headers. If software de-references an rdfs:seeAlso object and only expects RDF then it should have a suitable accept header. if the server can't respond with that content type, there are codes to handle that. RDF often comes in the form of RDFa, which doesn't have a separate media type from that of the host language. There are also custom provisions for RDF in OpenDocument and PDF as far as I understand. But I agree that using a property to indicate non-RDF content might be conflating things, as format is orthogonal to the role of the relation. Maybe something like this could work: /foo rdfs:seeAlso /bar . /bar a see:HumanReadableOnlyDescription ; dcterms:format http://example.net/text/html . -- Vasiliy Faronov
Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
I know it is not the same, but I use a combination of the ORE aggregation and the dc:format terms when I publish my presentation slides in different formats. This is really relevant if you have a document that has different formats but is the same logical 'thing'. What I do, roughly, is: @prefix ore: http://www.openarchives.org/ore/terms/ . @prefix dc: http://purl.org/dc/terms/ . http://www.w3.org/2010/1124-Amsterdam-IH/#talk a ore:Aggregation ; ore:aggregates http://www.w3.org/2010/Talks/1124-Amsterdam-IH/Talk.pdf, . http://www.w3.org/2010/Talks/1124-Amsterdam-IH/Talk.pdf a ore:AggregatedResource ; dc:format http://purl.org/NET/mediatypes/application/pdf . If you have something like that, you can the do a rdfs:seeAlso http://www.w3.org/2010/1124-Amsterdam-IH/#talk . Would that help? Caveat: the purl.org/NET/mediatypes includes only the formally registered media type, eg, not (yet?) Turtle... but that is a different thread... Ivan On Jan 6, 2011, at 20:40 , Peter DeVries wrote: I was wondering if there is an existing predicate for linking to a PDF file? I would like to incorporate a link between bibliographic reference description and a URL to the location of a PDF of that document. I had minted a predicate txn:hasPDFVersion, as demonstrated in this RDF snippet. (Part of http://lod.taxonconcept.org/ses/v6n7p.rdf ) txn:SpeciesOriginalDescription rdf:about=http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription; !-- Ideally, this should link to a resource in the Biodiversity Heritage Library -- dcterms:titleOriginal Published Description relating to Species Concept Puma concolor se:v6n7p/dcterms:title dcterms:identifierhttp://lod.taxonconcept.org/ses/v6n7p#OriginalDescription/dcterms:identifier dcterms:descriptionLOD metadata about the original species description relating to Species Concept Puma concolor se:v6n7p/dcterms:description dcterms:isPartOf rdf:resource=http://lod.taxonconcept.org/ses/v6n7p#Species/ txn:hasAuthorURI rdf:resource=http://dbpedia.org/resource/Carl_Linnaeus/ txn:hasBasionymNameFelis concolor Linnaeus 1771/txn:hasBasionymName txn:year1771/txn:year txn:hasPDFVersion rdf:resource=http://assets.geospecies.org/spec_concept_uuid/603bebac-cc44-4168-bbf7-b11b976f9d79/Felis_concolor_Linnaeus_1771.pdf/ txn:speciesOriginalDescriptionHasSpeciesConcept rdf:resource=http://lod.taxonconcept.org/ses/v6n7p#Species/ !-- There should be a type specimen. Add link to GBIF via 'txn:sodHasTypeSpecimen' if they know about it. -- wdrs:describedBy rdf:resource=http://lod.taxonconcept.org/ses/v6n7p.rdf/ /txn:SpeciesOriginalDescription Some have suggested using rdfs:seeAlso to link to what could be a multimegabyte PDF, but I think this would cause problems for a number of RDF crawlers like Elmo. In summary, I think it would be useful to have a predicate that can be used for linking specifically to a PDF document. Is there an existing predicate for this? What do people think about the suggestion to use rdfs:seeAlso to link to a PDF? I would also like to know of others thoughts or suggestions regarding this issue, Respectfully, - Pete --- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base / GeoSpecies Knowledge Base About the GeoSpecies Knowledge Base Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf smime.p7s Description: S/MIME cryptographic signature
Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
* [2011-01-10 08:55:59 +] Phil Archer phil.arc...@talis.com écrit: ] However... a property should not imply any content type AFAIAC. That's ] the job of the HTTP Headers. If software de-references an rdfs:seeAlso ] object and only expects RDF then it should have a suitable accept ] header. if the server can't respond with that content type, there are ] codes to handle that. I disagree that we should rely on HTTP headers for this. Consider local processing of a large multi-graph dataset. These kinds of properties can act as hints to process one graph or another without the need to dereference something. (tending to think of graph as equivalent to document obtained by dereferencing the graph's name). Slightly more esoteric are graphs made available over ftp, finger, freenet, etc.. Let's take advantage of HTTP where appropriate but not mix up the transport and content unnecessariy. Cheers, -w -- William Waitesmailto:w...@styx.org http://eris.okfn.org/ww/ sip:w...@styx.org 9C7E F636 52F6 1004 E40A E565 98E3 BBF3 8320 7664
Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
Hmmm... no, sorry, William, I think we're destined to disagree. On the Web in general, URIs don't, or certainly shouldn't, imply any particular content type. It is perfectly valid, for example, to return a PNG image from a URI that ends in .gif (awkward, unexpected, probably silly, but not 'wrong', especially if the Accept Headers indicate a preference for PNG over GIF). RDF does not require any URI to be dereferencable so that, as you say, you can process a graph without having to dereference anything. If you /do/ dereference a URI you might get a 406 Not Acceptable response, which, IMHO, is as valid as any other (and I'm trying hard not to reopen the 303 debate yet again here!!). If the User Agent can only accept certain content types then it should make that explicit in is request headers and be ready to handle a 406 in some intelligent way. Phil. On 10/01/2011 12:45, William Waites wrote: * [2011-01-10 08:55:59 +] Phil Archerphil.arc...@talis.com écrit: ] However... a property should not imply any content type AFAIAC. That's ] the job of the HTTP Headers. If software de-references an rdfs:seeAlso ] object and only expects RDF then it should have a suitable accept ] header. if the server can't respond with that content type, there are ] codes to handle that. I disagree that we should rely on HTTP headers for this. Consider local processing of a large multi-graph dataset. These kinds of properties can act as hints to process one graph or another without the need to dereference something. (tending to think of graph as equivalent to document obtained by dereferencing the graph's name). Slightly more esoteric are graphs made available over ftp, finger, freenet, etc.. Let's take advantage of HTTP where appropriate but not mix up the transport and content unnecessariy. Cheers, -w -- Phil Archer Talis Systems Ltd, Web: http://www.talis.com Tel: +44 1473 434770 Twitter: philarcher1 LinkedIn: http://uk.linkedin.com/in/philarcher Personal: http://philarcher.org
Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
On Sun, 2011-01-09 at 18:21 +0300, Vasiliy Faronov wrote: Maybe it's time to define several specializations of rdfs:seeAlso with stronger semantics? Don't we already have enough of those? s powder-s:describedby o . # o provides some more information about o, often in a # machine-readable format. s rdfs:seeAlso o . # Like powder-s:describedby but perhaps more tangential. # o might have information on something similar to s; or # if s is a document, o might have information on the # things described by s. s foaf:page o . # o provides information about s, often in a human-readable # format. s rdfs:isDefinedBy o . # o provides the canonical definition of s . We also have foaf:isPrimaryTopicOf, various terms from the XHTML vocabulary (xhv:meta, xhv:next, xhv:prev, etc), various terms from Dublin Core (dc:source, dc:relation, dc:replaces/isReplacedBy, dc:references/isReferencedBy, dc:hasVersion/isVersionOf, dc:hasPart/isPartOf, dc:isFormatOf/hasFormat) and countless others. To answer the original question, I'd say foaf:page is a better predicate than rdfs:seeAlso for a large PDF. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
On Mon, 2011-01-10 at 08:55 +, Phil Archer wrote: I'd be happy enough to see greater granularity for rdfs:seeAlso. I have a use case where I want to say something like the uri has been minted recently by a source that is not authoritative but that, if widely adopted, could become so. Either way, it's worth noting that he and I are talking about the same thing - and rdfs:seeAlso doesn't really cover that nuance! @prefix dc: http://purl.org/dc/terms/ . @prefix uri: http://purl.org/NET/uri# . @prefix rdfs: http://www.w3.org/2000/01/rdf-schema# . @prefix xsd: http://www.w3.org/2001/XMLSchema# . foo rdfs:seeAlso http://example.com/bar . http://example.com/bar uri:identifier [ uri:literal http://example.com/bar^^xsd:anyURI ; dc:issued 2011-01-08^^xsd:date ; u:policy _:ExampleDotComUriPolicy ; u:assigned_by http://example.com/alice#me ] . _:ExampleDotComUriPolicy rdfs:comment These URIs are not authoritative, but may become so.@en . -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
On 01/10/2011 01:45 PM, William Waites wrote: * [2011-01-10 08:55:59 +] Phil Archer phil.arc...@talis.com écrit: ] However... a property should not imply any content type AFAIAC. That's ] the job of the HTTP Headers. If software de-references an rdfs:seeAlso ] object and only expects RDF then it should have a suitable accept ] header. if the server can't respond with that content type, there are ] codes to handle that. I disagree that we should rely on HTTP headers for this. Consider local processing of a large multi-graph dataset. These kinds of properties can act as hints to process one graph or another without the need to dereference something. (tending to think of graph as equivalent to document obtained by dereferencing the graph's name). Slightly more esoteric are graphs made available over ftp, finger, freenet, etc.. Let's take advantage of HTTP where appropriate but not mix up the transport and content unnecessariy. Cheers, -w I agree, there is nothing wrong in having a subProperty which includes more information, whether it be about the subject or object of the triple, regardless if it's about content type or anything else. I believe it is good practice to specify domain and range of property in as precisely as possible. Failing to do so begs for usage which either is wrong by the original intention or making the meaning of the property very fuzzy, which in both cases results in less useful data. Best, Jiri signature.asc Description: OpenPGP digital signature
Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
Phil Archer wrote: On the Web in general, URIs don't, or certainly shouldn't, imply any particular content type. They don't imply anything, they name things, and the thing that's named can by all means be a representation with a specific mediatype, infact this is by far the most common usage of URIs, and always has been.
Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
On 10/01/2011 14:16, Nathan wrote: Phil Archer wrote: On the Web in general, URIs don't, or certainly shouldn't, imply any particular content type. They don't imply anything, they name things, and the thing that's named can by all means be a representation with a specific mediatype, infact this is by far the most common usage of URIs, and always has been. True, of course. But the fact that the identified resource is only available in a single representation is not denoted by the identifier. One might have reasonable expectations about http://example.com/index.html but no more. The only authoritative declaration of the content type of a resource is given in the HTTP response headers received when dereferencing the identifier. -- Phil Archer Talis Systems Ltd, Web: http://www.talis.com Tel: +44 1473 434770 Twitter: philarcher1 LinkedIn: http://uk.linkedin.com/in/philarcher Personal: http://philarcher.org
Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
On Пнд, 2011-01-10 at 13:04 +, Toby Inkster wrote: Don't we already have enough of those? Maybe we do, but then it's an issue of best practice consensus and documentation. I think both publishers and consumers could benefit from a broadly-agreed-upon list of common link types with appropriate predicates. s powder-s:describedby o . # o provides some more information about o, often in a # machine-readable format. Or could as well be a 15M PDF. An autonomous LD client cannot tell. An informal recommendation like use wdrs:describedby to point to a terse and authoritative RDF description and/or wdrs:describedby is equivalent to a follow-your-nose description would help. Then again, nothing in the POWDER spec says it shouldn't be a 15M PDF. So we kind of imbue a predicate with semantics it doesn't have according to the standard. A separate term with a clear specification would avoid this problem and everyone could rely on it. s rdfs:seeAlso o . # Like powder-s:describedby but perhaps more tangential. As Tim's email suggests, this interpretation is not universal. s rdfs:isDefinedBy o . # o provides the canonical definition of s . It's clear what a definition is for an RDFS vocabulary term, but not clear if I can apply this to instance data. Is authoritative description synonymous with definition? Does anyone use isDefinedBy for things other than classes and properties? -- Vasiliy Faronov
Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
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
Re: best practice relation for linking to image/machine-opaque docs? biomedical use case
[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 ti...@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
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 ti...@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
Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
Thanks to everyone. I fixed the issues with wdrs:describedby, used dcterms:hasFormat to link to the PDF the #OriginalDescription section now shows. txn:SpeciesOriginalDescription rdf:about= http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription; !-- Ideally, this should link to a resource in the Biodiversity Heritage Library -- dcterms:titleOriginal Published Description relating to Species Concept Puma concolor se:v6n7p/dcterms:title dcterms:identifier http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription /dcterms:identifier dcterms:descriptionLOD metadata about the original species description relating to Species Concept Puma concolor se:v6n7p/dcterms:description dcterms:isPartOf rdf:resource= http://lod.taxonconcept.org/ses/v6n7p#Species/ dcterms:creator rdf:resource=http://dbpedia.org/resource/Carl_Linnaeus/ txn:hasBasionymNameFelis concolor Linnaeus 1771/txn:hasBasionymName dcterms:created rdf:datatype=http://www.w3.org/2001/XMLSchema#gYear 1771/dcterms:created dcterms:hasFormat rdf:resource= http://assets.geospecies.org/spec_concept_uuid/603bebac-cc44-4168-bbf7-b11b976f9d79/Felis_concolor_Linnaeus_1771.pdf / txn:speciesOriginalDescriptionHasSpeciesConcept rdf:resource= http://lod.taxonconcept.org/ses/v6n7p#Species/ !-- There should be a type specimen. Add link to GBIF via 'txn:sodHasTypeSpecimen' if they know about it. -- wdrs:describedby rdf:resource=http://lod.taxonconcept.org/ses/v6n7p.rdf / /txn:SpeciesOriginalDescription rdf:Description rdf:about= http://assets.geospecies.org/spec_concept_uuid/603bebac-cc44-4168-bbf7-b11b976f9d79/Felis_concolor_Linnaeus_1771.pdf dcterms:formatapplication/pdf/dcterms:format /rdf:Description Here is the link to the entire RDF for this species http://lod.taxonconcept.org/ses/v6n7p.rdf I have updated the CKAN information http://ckan.net/package/taxonconcept http://ckan.net/package/taxonconceptand the void http://lod.taxonconcept.org/ontology/void.rdf The RDF dump files have been updated. http://lod.taxonconcept.org/ontology/void.rdfThe semantic sitemap is here http://lod.taxonconcept.org/sitemap.xml.gz http://lod.taxonconcept.org/sitemap.xml.gzI still have not figured out the best way to generate the interlink counts but the CKAN numbers are close. There are probably still errors or suboptimal semantic markup in these or their related ontology. I would welcome any suggestions or comments on ways to make these better. With each iteration I have been trying to add additional information that makes it easier to determine what is a and what is not an instance of one of the species concepts. It will take a while for these to get to what they should be. Thanks Again, Respectfully, - Pete On Mon, Jan 10, 2011 at 9:01 AM, Tim Berners-Lee ti...@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 -- --- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base http://www.taxonconcept.org/ / GeoSpecies Knowledge Base http://lod.geospecies.org/ About the GeoSpecies Knowledge Base http://about.geospecies.org/
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-requ...@w3.org [mailto:public-semweb- lifesci-requ...@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 ti...@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
RE: best practice relation for linking to image/machine-opaque docs? biomedical use case
Interesting. In case you weren't aware, we've done quite a bit on semantic image annotation and creating and XML schema for specifying regions of images and the ontology terms to describe them.. I have a number of papers on this on my web site if you're interested.. Daniel ___ Daniel L. Rubin, MD, MS Assistant Professor Department of Radiology | Stanford University Richard M. Lucas Center | 1201 Welch Road, Office P285 Stanford, CA 94305-5488 Phone: 650-723-9495 | Fax: 650-723-5795 Web: http://rubin.web.stanford.edu/ -Original Message- From: Tim Clark [mailto:tim_cl...@harvard.edu] 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 ti...@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
Re: best practice relation for linking to image/machine-opaque docs? biomedical use case
We have also been working on semantic tagging of image parts, from the microscopy realm. We have been working in this area with our Web Image Browser. This system is designed for annotation of extrememly large images coming from light and electron microscopy. A demo can be seen at: http://ccdb-portal.crbs.ucsd.edu/WebImageBrowser/cgi-bin/start.pl?imagePath=http://ccdb-portal.crbs.ucsd.edu:8081/ZoomifyDataServer/data/MP_23_rec The annotation creates a simple model of EQ (entity quality) drawing on the NIF ontologies through an autocomplete function. In the View xml function, you can see the xml that we use to relate the annotations to the geometry. The next step will be to specify these geometries in brain coordinates if the data are registered to our Whole Brain Catalog (http://wholebraincatalog.org) or some other coordinate system. Maryann On Jan 10, 2011, at 12:48 PM, Tim Clark wrote: Hi Michael, The default is assumed to be pixels. Thanks very much for the suggestion regarding GeIML. Subclasses of AO's Selector class have been worked through in some detail for annotating text, but have not received comparably detailed attention for images. This is something we are hoping to do in the future, particularly for biomedical imaging. Collaborators interested in working with us on this topic are welcome. Kind regards, Tim On Jan 10, 2011, at 3:28 PM, Michael Miller wrote: 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-requ...@w3.org [mailto:public-semweb- lifesci-requ...@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
Call for Papers: i-Society 2011!
Apologies for cross-postings. Please send it to interested colleagues and students. Thanks! CALL FOR PAPERS *** International Conference on Information Society (i-Society 2011), Technically Co-Sponsored by IEEE UK/RI Computer Chapter 27-29 June, 2011, London, UK www.i-society.eu *** The International Conference on Information Society (i-Society 2011) is Technically Co-Sponsored by IEEE UK/RI Computer Chapter. The i-Society is a global knowledge-enriched collaborative effort that has its roots from both academia and industry. The conference covers a wide spectrum of topics that relate to information society, which includes technical and non-technical research areas. The mission of i-Society 2011 conference is to provide opportunities for collaboration of professionals and researchers to share existing and generate new knowledge in the field of information society. The conference encapsulates the concept of interdisciplinary science that studies the societal and technological dimensions of knowledge evolution in digital society. The i-Society bridges the gap between academia and industry with regards to research collaboration and awareness of current development in secure information management in the digital society. The topics in i-Society 2011 include but are not confined to the following areas: *New enabling technologies - Internet technologies - Wireless applications - Mobile Applications - Multimedia Applications - Protocols and Standards - Ubiquitous Computing - Virtual Reality - Human Computer Interaction - Geographic information systems - e-Manufacturing *Intelligent data management - Intelligent Agents - Intelligent Systems - Intelligent Organisations - Content Development - Data Mining - e-Publishing and Digital Libraries - Information Search and Retrieval - Knowledge Management - e-Intelligence - Knowledge networks *Secure Technologies - Internet security - Web services and performance - Secure transactions - Cryptography - Payment systems - Secure Protocols - e-Privacy - e-Trust - e-Risk - Cyber law - Forensics - Information assurance - Mobile social networks - Peer-to-peer social networks - Sensor networks and social sensing *e-Learning - Collaborative Learning - Curriculum Content Design and Development - Delivery Systems and Environments - Educational Systems Design - e-Learning Organisational Issues - Evaluation and Assessment - Virtual Learning Environments and Issues - Web-based Learning Communities - e-Learning Tools - e-Education *e-Society - Global Trends - Social Inclusion - Intellectual Property Rights - Social Infonomics - Computer-Mediated Communication - Social and Organisational Aspects - Globalisation and developmental IT - Social Software *e-Health - Data Security Issues - e-Health Policy and Practice - e-Healthcare Strategies and Provision - Medical Research Ethics - Patient Privacy and Confidentiality - e-Medicine *e-Governance - Democracy and the Citizen - e-Administration - Policy Issues - Virtual Communities *e-Business - Digital Economies - Knowledge economy - eProcurement - National and International Economies - e-Business Ontologies and Models - Digital Goods and Services - e-Commerce Application Fields - e-Commerce Economics - e-Commerce Services - Electronic Service Delivery - e-Marketing - Online Auctions and Technologies - Virtual Organisations - Teleworking - Applied e-Business - Electronic Data Interchange (EDI) *e-Art - Legal Issues - Patents - Enabling technologies and tools *e-Science - Natural sciences in digital society - Biometrics - Bioinformatics - Collaborative research *Industrial developments - Trends in learning - Applied research - Cutting-edge technologies * Research in progress - Ongoing research from undergraduates, graduates/postgraduates and professionals Important Dates: Paper Submission Date: March 31, 2011 Short Paper (Extended Abstract or Work in Progress): March 20, 2011 Notification of Paper Acceptance /Rejection: April 15, 2011 Notification of Short Paper (Extended Abstract or Work in Progress) Acceptance /Rejection: April 10, 2011 Camera Ready Paper and Short Paper Due: April 30, 2011 Participant(s) Registration (Open): January 1, 2011 Early Bird Attendee Registration Deadline (Authors only): February 1 to April 30, 2011 Late Bird Attendee Registration Deadline (Authors only): May 1 to June 1, 2011 Conference Dates: June 27-29, 2011 For more details, please visit www.i-society.eu
RE: best practice relation for linking to image/machine-opaque docs? biomedical use case
Hi, For example: http://stanford.edu/~rubin/pubs/Rubin-IEEEIntelSys-2009.pdf http://stanford.edu/~rubin/pubs/Channin-JDI-2009.pdf or others there on Annotation and Image Markup.. Daniel ___ Daniel L. Rubin, MD, MS Description: Description: Description: Description: cid:image001.jpg@01CB4E1D.AC3DA3D0 Assistant Professor Department of Radiology | Stanford University Richard M. Lucas Center | 1201 Welch Road, Office P285 Stanford, CA 94305-5488 Phone: 650-723-9495 | Fax: 650-723-5795 Web: http://rubin.web.stanford.edu/ http://rubin.web.stanford.edu/ From: Paolo Ciccarese [mailto:paolo.ciccar...@gmail.com] Sent: Monday, January 10, 2011 12:57 PM To: Daniel Rubin Cc: Tim Clark; M. Scott Marshall; HCLS IG; public-lod@w3.org; John F. Madden; Vasiliy Faronov; Toby Inkster; Peter DeVries; Tim Berners-Lee; Anita de Waard; Maryann Martone Subject: Re: best practice relation for linking to image/machine-opaque docs? biomedical use case Dear Daniel, I am very interested in revising the material you have related to image fragments identification. I just had a look of your website, could you help me in selecting the 2 or 3 papers that you consider most appropriate in this context? Thank you Paolo On Mon, Jan 10, 2011 at 3:49 PM, Daniel Rubin dlru...@stanford.edu wrote: Interesting. In case you weren't aware, we've done quite a bit on semantic image annotation and creating and XML schema for specifying regions of images and the ontology terms to describe them.. I have a number of papers on this on my web site if you're interested.. Daniel ___ Daniel L. Rubin, MD, MS Assistant Professor Department of Radiology | Stanford University Richard M. Lucas Center | 1201 Welch Road, Office P285 Stanford, CA 94305-5488 Phone: 650-723-9495 | Fax: 650-723-5795 Web: http://rubin.web.stanford.edu/ -Original Message- From: Tim Clark [mailto:tim_cl...@harvard.edu] 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
