Re: Three steps

Hi Shlomo!

I've put a pure RDFa Lite version of your attached example in this
gist: https://gist.github.com/4169167

I agree with Richard in recommending the use of RDFa. Given its
inherent RDF nature, this benefits format independence and provides a
natural ability to mix multiple domain specific vocabularies.

(Disclaimer: I'm a member of the RDFa WG.)

Best regards,
Niklas


On Thu, Nov 29, 2012 at 1:57 PM, Shlomo Sanders
<Shlomo.Sanders@exlibrisgroup.com> wrote:
> See below
>
>
>
> Richard,
>
>
>
> Attached is an example record (I think I got if from the schema.org).
>
> Can you clean it up so that it is clean/pure/up-to-date RDFa?
>
>
>
> Thanks
>
> Shlomo
>
>
>
> From: Richard Wallis [mailto:richard.wallis@oclc.org]
> Sent: Thursday, November 29, 2012 14:37
> To: Shlomo Sanders; Alf Eaton
> Cc: public-schemabibex@w3.org; Young,Jeff (OR); Vizine-Goetz,Diane
> Subject: 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.
> [Shlomo] Be nice to see clean/pure/up-to-date RDFa examples.
>
>
>
> 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. [Shlomo] Right
>
>
> 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.
>
> [Shlomo] This is our plan
>
>
> 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.
>>>>
>>>>
>>>
>>>
>>
>

Received on Thursday, 29 November 2012 13:47:37 UTC