- From: Kevin Ford <kefo@3windmills.com>
- Date: Fri, 25 Jan 2013 19:28:44 -0500
- To: public-schemabibex@w3.org
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