RE: Three steps

We have 2 different scenarios:
•       HTML markup - Here we need to decide if one, the other or both. The page size is large as it is.
•       Linked Data (RESTful) API - We plan on the having a parameter on the URI that will indicate which encoding to use (i.e. RDFa Lite, LC format - whatever that is) so we should not have to put both into the API results.


-----Original Message-----
From: Alf Eaton [mailto:eaton.alf@gmail.com]
Sent: Thursday, November 29, 2012 13:25
To: Shlomo Sanders
Cc: public-schemabibex@w3.org
Subject: Re: Three steps

You're probably producing HTML + microdata, not XML, so something like this should work nicely:

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

A simpler alternative (for this specific case) would be this:

<a itemprop="author"
href="http://id.loc.gov/authorities/names/n50016589">J.D. Salinger</a>

As for "vocab", "typeof" and "property" attributes, they're part of a different system for marking up metadata (RDFa Lite). The choice of whether to use microdata or RDFa (Lite), or both, is a VHS vs Betamax
choice: it depends on which you prefer, and which consumers of the data that you produce prefer.

On 29 November 2012 09:45, Shlomo Sanders <Shlomo.Sanders@exlibrisgroup.com<mailto:Shlomo.Sanders@exlibrisgroup.com>> wrote:
> So, based on your answers this is perhaps the proper XML if we need to
> keep the size down?
>
> <span itemprop="author" itemscope='i' itemtype="http://schema.org/Person"
> itemid="http://id.loc.gov/authorities/names/n50016589">
>      <span itemprop="name">J.D. Salinger</span> </span>
>
> If we were to add to this, the order of preference would be to add:
> •       Vocab
> •       Property - Still unclear why I need/want to have this duplicated
> tag. What good does it do me or someone else?
>
> As for granularity of the name (name vs. given and family) I think the
> simple name is better if there is an itemid.
> If there isn’t an itemid then perhaps better to split into given and family.
>
> Thanks
> Shlomo
>
> -----Original Message-----
> From: Alf Eaton [mailto:eaton.alf@gmail.com]
> Sent: Thursday, November 29, 2012 11:16
> To: Shlomo Sanders
> Cc: public-schemabibex@w3.org
> Subject: Re: Three steps
>
> On 29 November 2012 06:32, Shlomo Sanders
> <Shlomo.Sanders@exlibrisgroup.com<mailto:Shlomo.Sanders@exlibrisgroup.com>>
> wrote:
>
>> I am looking at this snippet that I got from schema.org
>>
>>           <li itemprop="author" property="author" itemscope="itemscope"
>> itemtype="http://schema.org/Person" vocab="http://schema.org/"
>> typeof="Person">
>>              <span itemprop="name" property="name">
>>                 <span itemprop="givenName"
>> property="givenName">Gerhild</span>
>>                 <span itemprop="familyName"
>> property="familyName">Wildner</span>
>>              </span>
>>           </li>
>>
>> How does itemscope="itemscope" help?
>
> The itemscope attribute is redundant in most places, when itemtype is
> also present; itemtype isn't a requirement, though, so itemscope is
> always used to mark the start of an object.
>
>> What is the purpose of having both itemprop and property?
>
> "itemprop" and "itemtype" are HTML5 microdata attributes, "property"
> and "vocab" are RDFa Lite attributes.
>
>> The following snippet appeared in mail from Jason Ronallo:
>>    <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>
>>
>> In this example itemscope appears with no value. Is that just typo?
>
> In HTML, attributes such as "itemscope", "checked", "disabled", etc do
> not need to have a value - values are only required in XML.
>
>> No vocab. Is that OK?
>> No property, just itemtype.
>
> "vocab" and "property" are RDFa Lite attributes, so are not required
> if the implementation is only using microdata.
>
>>
>> We agreed that itemid=http://id.loc.gov/authorities/names/n50016589

>> is what we want but is optional, right?
>
> itemid is always optional, as far as I know.
>
>>
>> Shlomo
>>
>>
>> -----Original Message-----
>> From: Kevin Ford [mailto:kefo@3windmills.com]
>> Sent: Wednesday, November 28, 2012 17:31
>> To: public-schemabibex@w3.org
>> Subject: Re: Three steps
>>
>> Just to add support to Jason's note, the "itemid" property he
>> included in his last example would be ideal, but not mandatory.
>>
>> 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<mailto:richard.wallis@oclc.org%20<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.
>>>
>>>
>>
>>
>