Re: Three steps

On Nov 28, 2012, at 11:26 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:

> 
> 
> 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.
> 
> At some past ALA meeting of the Linked Library Data group I did a lightning talk on possible library use of schema.org. The motivation, as I saw it (and still do) is that if you can make a change that is ONLY a change to the HTML page display -- that doesn't affect the database, the cataloging modules, the UI, or anything else that would require significant changes to the ILS software -- then we might be able to get vendors to add linked data to the systems as a display-only feature. This solution has lots of advantages, not the least being that it doesn't even require a change in the user interface since it will be ignored by the browser.
> 
> 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.
> 
> (Hmmm. Anyone here involved with OS library systems? That sounds like a good place to start.)

We're "just" talking about display data, though, right?  Any (and all) ILMS with (decent) access to the display templates should work for proof of concept purposes, shouldn't it?

Another place to try to implement this could be a link resolver, for articles.

-Ross.
> 
> kc
> 
>> 
>> We can model People/Organizations, and their relations to CreativeWorks,
>> per the current Schema.org guidelines.  It's just that those libraries
>> that do not have the technological capability to either mint a URI for a
>> Person/Organization or make use of an already minted URI for the same
>> can omit the "href" or "itemid" property.  In RDF terms, it just results
>> in a blank node.  Perhaps not ideal, but perfectly acceptable.
>> 
>> In any event, the examples at the bottom of http://schema.org/Book for
>> "Reviews" omit the "Person" itemtype construct altogether for a simple
>> lexical string.
>> 
>> Yours,
>> 
>> Kevin
>> 
>> 
>> 
>> On 11/28/2012 09:52 AM, Jason Ronallo wrote:
>>> Richard,
>>> 
>>> It seems to me that Schema.org is already relaxed about these kinds of
>>> problems. The value of the author property is _expected_ to be a Person
>>> or Organization. Consuming applications on the other hand should expect
>>> to get imperfect data, though. Even the Schema.org documentation for a
>>> book uses a relative URL from the href to refer to the author. Here's a
>>> snippet:
>>> 
>>> <div itemscope itemtype="http://schema.org/Book">
>>>   <span itemprop="name">The Catcher in the Rye</span>
>>>   by <a itemprop="author" href="/author/jd_salinger.html">J.D.
>>> Salinger</a>
>>> </div>
>>> 
>>> But maybe this is a bug?
>>> 
>>> As a consuming application I would also expect to see something like
>>> this where a string is used:
>>> 
>>> <div itemscope itemtype="http://schema.org/Book">
>>>   <span itemprop="name">The Catcher in the Rye</span>
>>>   by <span itemprop="author">J.D. Salinger</span>
>>> </div>
>>> 
>>> But if you are an implementer, read the documentation, and all you have
>>> is an author name as a string, there is nothing keeping you from being
>>> more exact with that and doing something like the following. This is
>>> probably what the recommendation ought to be if you only have an author
>>> name as a string.
>>> 
>>> <div itemscope itemtype="http://schema.org/Book">
>>>   <span itemprop="name">The Catcher in the Rye</span>
>>>   by <span itemprop="author" itemscope
>>> itemtype="http://schema.org/Person"><span itemprop="name">J.D.
>>> Salinger</span></span>
>>> </div>
>>> 
>>> If you also have some kind of identifier for the person, then you could
>>> add an itemid:
>>> 
>>> <div itemscope itemtype="http://schema.org/Book">
>>>   <span itemprop="name">The Catcher in the Rye</span>
>>>   by <span itemprop="author" itemscope
>>> itemtype="http://schema.org/Person"
>>> itemid="http://id.loc.gov/authorities/names/n50016589"><span
>>> itemprop="name">J.D. Salinger</span></span>
>>> </div>
>>> 
>>> So while recommendations to the community would be to be as exact as
>>> possible there is no requirement that it be so strict.
>>> 
>>> Jason
>>> 
>>> 
>>> 
>>> On Wed, Nov 28, 2012 at 7:09 AM, Richard Wallis <richard.wallis@oclc.org
>>> <mailto:richard.wallis@oclc.org>> wrote:
>>> 
>>>    I’m stepping out of the thread that seems to have developed an all
>>>    encompassing life of its own [Itemprop for person] to pick up on an
>>>    issue identified in the recent contributions between Karen and
>>> myself.
>>> 
>>>    This is the example of how to represent the author when marking up a
>>>    work (for now lets assume a book with person as an author).
>>> 
>>>    I said that the author property of the Book should be a URI to a
>>>    description of a Person (either a local Person description that
>>>    onward links to authority like VIAF, or a direct link to an
>>> authority).
>>> 
>>>    Karen, quite rightly came, back to say that a library may only have
>>>    a string of characters for the author name so can not do what I
>>>    describe.
>>> 
>>>    This sort of scenario leads me to suggest that we approach such
>>>    descriptive challenges in a three step process:
>>> 
>>>     1. How to describe what we have, using Schema as it is
>>>     2. What changes/enhancements, if any, to Schema could we propose to
>>>        improve the description [and pragmatically expect the Schema
>>>        group to accept]
>>>     3. Provide examples/recipes for how the markup would look in each
>>> case
>>> 
>>> 
>>>    Applying this to the Book->author problem....
>>> 
>>>    Step 1.
>>>    schema:Book->author is a property that requires a link to a Person
>>>    or Organization – not a literal string.   Therefore example markup
>>>    would require links to Person description either externally supplied
>>>    or created locally on the fly.
>>> 
>>>    Step 2.
>>>    We only have a string for an author name, so why not suggest that
>>>    Schema relaxes the restrictions on Book->author to enable the use of
>>>    strings.  Taking account of the underlying philosophy behind Schema
>>>    (Things not Strings), it is exceedingly unlikely that such a
>>>    proposal would be accepted as it would break their related entities
>>>    model of the world.
>>> 
>>>    Step 3.
>>>    We need to provide examples of how we would markup various
>>>    situations that would cope with my ideal view and Karen’s real
>>>    situation of only having an author string – plus possibly a few
>>>    in-between.  I believe that it would be possible to satisfy Schema’s
>>>    need for a Person description (in this case with only a name
>>>    property) by creating a description in line on the fly.
>>> 
>>>    I am conscious that as a group we have not been good at sharing
>>>    example markup –  I include me in that, my RDFa is not as good as I
>>>    would like it to be – how we rectify this is something I ant to
>>>    address in the next call. (tomorrow)
>>> 
>>>    ~Richard.
>>> 
>>> 
>> 
>> 
> 
> -- 
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>

Received on Wednesday, 28 November 2012 16:56:36 UTC