Re: Three steps

Hi Shlomo,

Scenario 1
Following the, emerging, lead from the Shema.org community I would suggest
taking the RDFa route for embedding in html.  Although they started with
microdata [hence many of the documentation examples are microdata only],
RDFa is more capable of handling issues such as things being of multiple
types etc. - this is why they had to add the additionalType property to
Thing as a kludge to enable the microdata folks to represent multiple types.

Personally I would always lean towards RDFa, as the mapping to/from other
RDF formats (n-Triples, Turtle, RDF/XML, JSON) is is just a simple format
transformation.  Also it will make it easier for adding other RDF in to a
page to supplement Schema.org with some more domain specific stuff.

The search engines say that they intend to support both.

Scenario 2
I am [hopefully correctly] thinking that you are talking about an API to
output the raw data, without the html.

In which case I would not go for a specific API I would let the data URI be
it¹s own API, using content-negotiation to provide the RDF serialisation
format the user requests.

Implementation of this can be handled by http standard redirects from
<http://mylib.org/res/1234> to <http://mylib.org/res/1234.html>,
<http://mylib.org/res/1234.rdf>, <http://mylib.org/res/1234.json>,
<http://mylib.org/res/1234.ttl>, etc. dependant upon the Accept format in
the request.  Of course these individual output types also could be accessed
directly if required.

~Richard.

On 29/11/2012 12:04, "Shlomo Sanders" <Shlomo.Sanders@exlibrisgroup.com>
wrote:

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