RE: question about medical code

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 03:32:46 UTC