Re: question about medical code

Hi Jeff,

Definitely not. My apologies if I gave that impression. I completely
agree that, when it fits the spirit of a well-constructed model,
resources are preferable.

That said, I have a hard time with a proliferation of standards that
*require* a range of resource when doing so presents a barrier to
people's pragmatic efforts to publish data.

I've made this same argument with regard to dcterms: for years now. I
just don't see the downside to Kevin's suggestion that we might
"permit a string OR rdf:Resource as the range of the
inStandard/codingScheme property, and we encourage the use of the
latter".

Thanks,
-Corey


On Fri, Jan 25, 2013 at 9:47 PM, Young,Jeff (OR) <jyoung@oclc.org> wrote:
> Corey,
>
> As Kevin pointed out, Karen misunderstood me. Are you suggesting that strings really are better than things and that Schema.org would agree?
>
> http://googleblog.blogspot.com/2012/05/introducing-knowledge-graph-things-not.html
>
> As discussed in another thread, I have no problem with developers ignoring httpRange-14 and Cool URIs or the use cases that justify them. If the Web was replaced tomorrow I wouldn't fret because the models being developed transcend the Web.
>
> Jeff
>
>> -----Original Message-----
>> From: Corey Harper [mailto:corey.harper@gmail.com]
>> Sent: Friday, January 25, 2013 8:53 PM
>> To: Young,Jeff (OR)
>> Cc: Kevin Ford; public-schemabibex@w3.org
>> Subject: Re: question about medical code
>>
>> Hi Jeff, et al.,
>>
>> I'm inclined to agree with Karen here. I think a lot of libraries are
>> more trying to solve practical, near-term problems with schema.org and
>> may not be in a position to adopt the kinds of "proper linked data"
>> practices that we'd want in an ideal world. Setting aside your "if they
>> have access to the HTML production", which is not usually the case with
>> the current generation of ILS systems, even if folks did, we have a
>> tendency to set a pretty high barrier for that. Many of the libraries I
>> talk to are frankly scared of the prospect of minting "Cool URIs".
>> There's so many rules, and the semweb community can be rather pedantic
>> about them.
>>
>> People are scared of the notion that Cool URIs never change (really, a
>> redirect isn't a fair solution to that problem?) They're set in stone
>> for how long? The rhetoric makes people feel like they have to commit
>> to a URI for quite longer than we've even had a Web. Plus, there's all
>> the details of hash URIs vs. slash URIs with proper redirects between
>> things & pages that describe them. And I could go on. And on.
>>
>> But the point is that each of these requirements serves as a barrier to
>> libraries making their data available in a more machine usable form
>> than it exists now. Do we really want to say that if you're not in a
>> position to create clean, cruft-free, properly-range-14-compliant URIs
>> for everything you might wish to describe than we actually don't want
>> your structured data at all?
>>
>> What I see as the promise of schema.org is it's potential to *lower*
>> the bar for publishing the data folks have, using the systems they have
>> available.
>>
>> Sorry for the rant, but I worry that we're going to (again) shoot
>> ourselves in the foot by putting up roadblocks that very few in our
>> profession (and very few web developers *outside* of libraries) have
>> the time or energy to surmount.
>>
>> Thanks,
>> -Corey
>>
>> On Fri, Jan 25, 2013 at 8:03 PM, Young,Jeff (OR) <jyoung@oclc.org>
>> wrote:
>> > Kevin's got it. I would like to imagine schema:ConceptScheme (or
>> > something similar) instead of rdfs:Resource as the range for this
>> > property, but that's merely a detail.
>> >
>> > Coining proper Linked Data (hash) URIs matched up to some RDFa should
>> > be very easy if they have access to the HTML production.
>> >
>> > Once again, remember that Schema.org is automatically forgiving when
>> > people put strings where things are expected. That's true across the
>> > board. It shouldn't be necessary to think this property is any
>> > different.
>> >
>> > Jeff
>> >
>> >> -----Original Message-----
>> >> From: Kevin Ford [mailto:kefo@3windmills.com]
>> >> Sent: Friday, January 25, 2013 7:29 PM
>> >> To: public-schemabibex@w3.org
>> >> Subject: 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_appro
>> > a
>> >> ch_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 03:08:13 UTC