- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Fri, 25 Jan 2013 17:00:33 -0800
- To: "public-schemabibex@w3.org" <public-schemabibex@w3.org>
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