Re: question about medical code

On 1/26/13 5:37 AM, Corey Harper wrote:
> 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?

Ivan Herman expressed some similar concerns, but I believe he is 
traveling and may not have time to chime in. From his statements I got 
the impression that there may be an assumption that everything in 
schema.org has to be expressible *both* as microformat data AND as RDFa, 
using the same property declarations. I don't know if this has been 
stated as a requirement in the larger schema.org community, but I fear 
that it isn't practical, since it forces the looser microformat data 
metadata to follow RDFa requirements. We may thus lose the simplicity 
that some communities desire. Admittedly the microformat data may be 
less precise. Then again, what data people are putting in their web 
pages is often imprecise. I don't think we should try to force precision 
on them.

The question seems to be whether RDFa compliance is to be the test for 
every proposal for schema.org vocabularies. It definitely does not seem 
to have been in the past. Perhaps we need to ask this of DanBri?

kc


>
> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>
>

-- 
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 16:00:01 UTC