Re: question about medical code

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

Received on Saturday, 26 January 2013 00:29:12 UTC