- From: Corey Harper <corey.harper@gmail.com>
- Date: Fri, 25 Jan 2013 20:53:29 -0500
- To: "Young,Jeff (OR)" <jyoung@oclc.org>
- Cc: Kevin Ford <kefo@3windmills.com>, public-schemabibex@w3.org
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_approa >> 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 01:53:56 UTC