Re: question about medical code

Jeff et al,

The schema.org documentation page says that schema.org maps to RDFa *lite*.

"Our use of Microdata maps easily into RDFa Lite. In fact, all of 
Schema.org can be used with the RDFa Lite syntax as is. The RDFa Lite 
version of the markup looks almost isomorphic to the Microdata version. 
Given below is an sample RDFa Lite markup, of the example given for the 
Product type. "

The RDFa lite document [1] says:

"It must not use any additional RDFa attributes other than vocab, 
typeof, property, resource, and prefix; it may also use href and src, 
when the Host Language authorizes the usage of those attributes. 
However, even if authorized by the Host Language, the usage of rel and 
rev should be restricted to non-RDFa usage patterns, as defined by the 
Host Language."

and the examples look like:

<p vocab="http://schema.org/" prefix="ov: http://open.vocab.org/terms/" 
resource="#manu" typeof="Person">
    My name is
    <span property="name">Manu Sporny</span>
    and you can give me a ring via
    <span property="telephone">1-800-555-0199</span>.
    <img property="image" src="http://manu.sporny.org/images/manu.png" />
    My favorite animal is the <span 
property="ov:preferredAnimal">Liger</span>.
</p>

Am I correct in understanding that the examples on our wiki pages are 
RDFa, but not RDFa lite? Also, the vocabulary is also available as RDFa 
and OWL, but those are descriptions of the vocabulary, not instance 
data. Is there a move toward creating schema.org instance data that 
confirms to RDFa? I ask because I have looked through the schema.org 
site and don't see any examples that look like the RDFa ones on our pages.

kc
[1] http://www.w3.org/TR/rdfa-lite/



On 1/26/13 7:41 AM, Young,Jeff (OR) wrote:
> 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>

-- 
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:26:15 UTC