RE: question about medical code

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 02:47:49 UTC