RE: question about medical code

Corey,

Schema.org is nothing more than an RDF vocabulary. What leads you to believe otherwise?

http://schema.org/docs/datamodel.html


Jeff


> -----Original Message-----
> From: Corey Harper [mailto:corey.harper@gmail.com]
> Sent: Saturday, January 26, 2013 8:38 AM
> To: Young,Jeff (OR)
> Cc: Kevin Ford; public-schemabibex@w3.org
> Subject: 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 15:42:28 UTC