Re: question about medical code

Kevin, Thanks for the explanation. I agree with what you say, and of 
course URIs are better than strings, but I think that we will have to 
interact with communities that are at the "string" level, especially in 
schema.org. Since schema.org is very flexible, I believe that in 
practice we will get some things (URIs) and some strings, hopefully with 
the use of URIs growing.

Although there is a significant move toward RDFa, my understanding is 
that schema.org can also be used for microdata markup that will exist is 
varying levels of sophistication. Here's a chunk from the 
MedicalSignOrSymptom:

<div itemscope itemtype="http://schema.org/MedicalCondition">
   <h1><span itemprop="name">Stable angina</span>
     (<span itemprop="alternateName">angina pectoris</span>)</h1>
   <span itemprop="code" itemscope itemtype="http://schema.org/MedicalCode">
     <meta itemprop="code" content="413"/>
     <meta itemprop="codingSystem" content="ICD-9"/>
   </span>

If I am understanding you correctly, this example is missing the "coding 
system property" that you would like to see. Or am I mis-understanding? 
Because if this is what the medical community feels that it can do, then 
that's fine. I'm reluctant to make any requirements about minting URIs 
if that provides a barrier to folks entering into this environment.

kc

On 1/25/13 4:28 PM, Kevin Ford wrote:
> Dear Karen,
>
> Jeff was referring to the codingSystem property at [1], not the code
> itself.  (Richard proposed an alternate name for the property -
> inStandard - in an above example.)
>
> Both examples, however, represent the scheme to which the identifier
> conforms as simple strings.  Jeff, I believe, would prefer if the scheme
> to which the identifier conforms were referenced by URI.  As in:
>
> <http://bowker.com/identifiers/isbn/9780553479430>
>      a schema:Identifier;
>      schema:name "9780553479430";
>      schema:inStandard <http://id.loc.gov/vocabulary/identifiers/isbn> .
>
> Now, it might be that a string value *or* URI would be perfectly
> acceptable for the property schema:inStandard, but what I really wanted
> to comment on is slightly tangential because it involves the choices in
> modelling before you/us.
>
> schema:inStandard rdfs:range xsd:string
>
> is a popular and easy thing to do because it allows anyone to plug in
> their value.  However
>
> schema:inStandard rdfs:range rdf:Resource
>
> can lead to more information and better control.
>
> The former is easy for anyone to understand and produce, because they
> simply need to enter some text.  The latter, however, would require
> someone with a "special" identifier (i.e. an identifier type that has
> not been given its own URI) needing to mint a URI.
>
> That's not that hard for us to do or necessarily understand, but I find
> that this is one of those recurring issues with respect to Linked Data.
>   People have something custom, there's no URI, and he doesn't know what
> to do next.
>
> I don't have a real solution to offer (unless we permit a string OR
> rdf:Resource as the range of the inStandard/codingScheme property, and
> we encourage the use of the latter) but I didn't want to miss the
> opportunity to note that this is one of those issues that will recur
> and, however it pans out, requires some form of education.
>
> Yours,
> Kevin
>
> [1]
> http://www.w3.org/community/schemabibex/wiki/Identifier#Adopting_approach_from_medical.2Fhealth_extension
>
>
>
>
> On 01/25/2013 07:04 PM, Karen Coyle wrote:
>> Jeff, I believe that the issue is that the codes *are* strings, and
>> that's why they need this two-part description. If they were things we
>> wouldn't be having this conversation.
>>
>> kc
>>
>> On 1/25/13 12:29 PM, Young,Jeff (OR) wrote:
>>> I think they should model values for codingScheme as things rather than
>>> as strings. That would be the SKOS way. They already have a forgiveness
>>> clause for numbing things down to strings, but it's harder to row in the
>>> opposite direction.
>>>
>>> Jeff
>>>
>>>> -----Original Message-----
>>>> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
>>>> Sent: Friday, January 25, 2013 3:13 PM
>>>> To: public-schemabibex@w3.org
>>>> Subject: question about medical code
>>>>
>>>> Adrian has added the medical code to the Identifier page [1]. It looks
>>>> to me like in its simplest form it could also be used for the
>>>> minimalist approach to identifiers that I have proposed [2].
>>>> Essentially, it only needs two properties:
>>>>
>>>> codeValue     Text     The actual code.
>>>> codingSystem     Text     The coding system, e.g. 'ICD-10'.
>>>>
>>>> Of course, they have to be grouped as a single unit, which the medical
>>>> code page calls "code":
>>>>
>>>> code     MedicalCode     A medical code for the entity, taken from a
>>>> controlled vocabulary or ontology such as ICD-9, DiseasesDB, MeSH,
>>>> SNOMED-CT, RxNorm, etc.
>>>>
>>>> I must admit that I find the properties here to be a bit circular but
>>>> I'm going to assume that greater minds than mind have investigated
>>> this
>>>> and determined that it works.
>>>>
>>>> I could add an example on my simplified identifier page, and/or could
>>>> add a simplified example after Adrian's. Does that make sense?
>>>>
>>>> I have one worry about using "code" however: I think that we, too,
>>> will
>>>> have codes that need to be described in this way. Will there need to
>>> be
>>>> a difference between codes of this type and identifiers? It seems to
>>> me
>>>> that folks are often using "identifier" to me an identifier for the
>>>> focus of the description, whereas "code" could be, for example, a
>>>> description element like "audience level" or "government document
>>>> type."
>>>> In practical usage, will we need both?
>>>>
>>>> kc
>>>> --
>>>> Karen Coyle
>>>> kcoyle@kcoyle.net http://kcoyle.net
>>>> ph: 1-510-540-7596
>>>> m: 1-510-435-8234
>>>> skype: kcoylenet
>>>>
>>>
>>>
>>>
>>>
>>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Saturday, 26 January 2013 01:01:10 UTC