Re: Three steps

Karen said: "(Hmmm. Anyone here involved with OS library systems? That sounds like a good place to start.)" 


As I noted in the kick-off schemabibex call, I am an Evergreen library system developer, and have in fact already implemented some basic schema.org (which was released in Evergreen 2.3 this spring; so there are already a lot of libraries already publishing basic schema.org in the wild). 

Standard IDs and URLs are indeed where I ran into some trouble. I don't work in an OCLC library, and as far as I can tell OCLC IDs aren't freely available outside of the reclamation process, so OCLC IDs seem to be a non-starter from my perspective. I poked at Freebase a bit thinking that it might be a reasonable source of standard IDs for all kinds of media, but it doesn't have as many bibliographic entities as I thought it would, and OpenLibrary seems to be on shaky grounds these days. I ended up pointing at an internal relative author search URL as the href for the author entries, which feels horribly dirty. In retrospect, I probably should have left the <a href> for launching the "related author search" and embedded a <span itemprop="contributor"> for the co-authors to disambiguate the purposes of the markup. 

The Evergreen implementation is also limited currently to the schema.org Book and MusicRecording types at this point. Still, all drawbacks aside, I wanted to start somewhere, and hopefully I will be able to iterate on it from here. Which is why I was excited about the creation of this group. 

An example drawn from http://laurentian.concat.ca/eg/opac/record/729926 follows (edited a tad, as I noticed some breakage has crept into our local markup - sigh): 

<div id="canvas_main" class="canvas" itemscope="" itemtype="http://schema.org/Book"> 
<abbr class="unapi-id" title="tag:laurentian.concat.ca,2012:biblio-record_entry/729926"></abbr> 
<h1 id="rdetail_title" itemprop="name">The success of open source / Steven Weber.</h1> 
<div class="rdetail_authors_div"> 
    <span class="rdetail-author-div"><a href="/eg/opac/results?query=%20Weber%2C%20Steve%2C%201961-;qtype=author;locg=105;detail_record_view=1" itemprop="accountablePerson">Weber, Steve, 1961-</a> (Author). </span> 
</div> 
<ul> 
    <li class="rdetail_isbns"> 
        <strong class="rdetail_label">ISBN:</strong> 
        <span class="rdetail_value" itemprop="isbn">0674012925</span> 
    </li> 
    <li id="rdetail_phys_desc"> 
        <strong class="rdetail_label">Physical Description:</strong> 
        <span class="rdetail_value">viii, 312 p.</span> 
    </li> 
    <li id="rdetail_publisher"> 
        <strong class="rdetail_label">Publisher:</strong> 
        <span class="rdetail_value" itemprop="publisher" itemscope="" itemtype="http://schema.org/Organization"> 
            <span itemprop="location">Cambridge, MA :</span> 
            <span itemprop="name">Harvard University Press,</span> 
        </span> 
            <span itemprop="datePublished">2004.</span> 
    </li> 
</ul> 
<table class="rdetail_subject"> 
            <tbody> 
                <tr> 
                    <td class="rdetail_subject_type">Subject: </td> 
                    <td class="rdetail_subject_value" itemprop="keywords"> 
<a href="/eg/opac/results?query=Open%20source%20software.;qtype=subject;locg=105;detail_record_view=1">Open source software.</a><br></td> 
                </tr> 
            </tbody> 
        </table> 
</div> 


(Apologies for being so quiet, but last time I posted to this list offering up some use case ideas and offering to experiment creating a DAIA implementation, I think I was chastised for not writing in the wiki instead, so I've been somewhat gunshy about posting since.) 

>>> Karen Coyle <kcoyle@kcoyle.net> 11/28/2012 11:26 AM >>>

On 11/28/12 7:31 AM, Kevin Ford wrote:
> Just to add support to Jason's note, the "itemid" property he included
> in his last example would be ideal, but not mandatory.

Right. That's the element that, as I pointed out, most libraries using
standard ILSs do not have, and that I suspect they may not get in the
near future. So "not mandatory" is an essential message.
 
<snip>

This does mean that we will be going into the linked data space with the
data we have, not the data we wish we had. At least initially. I see
this as step 1, and in order to make this palatable to library systems
vendors I feel strongly that we need to present that simplest
possibility as a good and viable one.

We might want to look at our use cases and see if there are ways to
implement any of them with Step1 data. This will probably hinge on the
presence of ISBNs (or LCCNs?), but again that might be an encouragement
to vendors to make the change.