Re: question about medical code

There it is! Thank you, Jeff.

You're right that the medical code pattern won't scale if it's not
reusable. Can you say a bit more about why you feel it isn't reusable?
Is it just the specificity of the properties, or is it the pattern
itself? If the former, can't we just generalize it a bit and offer it
as an option alongside a more SKOS-like pattern?

I agree with you about the SKOS pattern. However, I also recognize the
reality that this & related RDF patterns are part of what schema.org
is trying to get away from. What I'd really like to see is a set of
principles that would allow publishers with the inclination to adopt
that pattern & use it within schema.org, but also provide guidance for
publishers that aren't there yet. Perhaps it's naive of me to think
that's possible, though.

Also, my use of the word "proliferation" was misplaced, but I agree
that our goal should be to try & reconcile standards.

-Corey

On Fri, Jan 25, 2013 at 10:32 PM, Young,Jeff (OR) <jyoung@oclc.org> wrote:
> This is one of those rare cases where the Subject: line still reflects the thread's origin and rambling trajectory. The medical code in Schema.org isn't reusable and repeating the pattern for a multitude of other standard codes isn't scalable. By recommending a more general pattern to Schema.org, the pattern (essentially SKOS) is unleashed and becomes open for serendipitous discovery. We aren't proliferating standards, we are reconciling them.
>
> Jeff
>
>> -----Original Message-----
>> From: Corey Harper [mailto:corey.harper@gmail.com]
>> Sent: Friday, January 25, 2013 10:08 PM
>> To: Young,Jeff (OR)
>> Cc: Kevin Ford; public-schemabibex@w3.org
>> Subject: 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-
>> thi
>> > ngs-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_appr
>> >> o
>> >> > 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 13:38:12 UTC