Re: journal article for next call?

Hi Antoine,

On Thu, Nov 28, 2013 at 2:00 AM, Antoine Isaac <aisaac@few.vu.nl> wrote:
> Hi Dan,
>
> On the collection aspect, you've definitely made me feel *really* strongly
> about the subclassing. That some (many) issues are collections, no doubts.
> But that some issues are *not* collections is enough to bar the general
> subclass option.

Hmm. At what point does the some / many / most rule tip back in favour
of issue-as-collection?

> And your theoretical treatment of 'atomic' issues as
> singleton sets, though formally elegant, is a no-go. We're here to keep
> things simple and intuitive, not to create solutions worth of the most
> complex formal ontologies.

I worry that the alternative that I think you proposed is in some ways
more complex... if I understand correctly, by "let data publishers use
an extra type assertion to Collection (and statements with the
"article" property) to indicate when an issuance is a composite item",
you were recommending that we use http://schema.org/alternativeType to
point at Collection (or the RDFa native equivalent)?

So to pull from the existing example of Issuance in the Periodical
proposal, instead of the current:

   <ul>
     <li property="issuance" typeof="Issuance">Volume <span
property="issueVolume">7</span>,
       issue <span property="issueNumber">6</span>
       <span property="datePublished">2007</span>
       pages <span property="pagination">543-633</span>
       <ul>
         <li property="article" typeof="ScholarlyArticle">
           <strong property="name"><span
property="articleSection">Opinion</span>:Trusting double-blind
peer-review</strong>,
           by <span property="author">Foo Bar</span>, p. <span
property="pagination">543-545</span>
         </li>
         <li> ... </li>
       </ul>
     </li>

the markup would add the Collection type to the Issuance level, like
so: (RDFa Lite)

   <ul>
     <li property="issuance" typeof="Issuance Collection">Volume <span
property="issueVolume">7</span>,
       issue <span property="issueNumber">6</span>
       <span property="datePublished">2007</span>
       pages <span property="pagination">543-633</span>
       <ul>
         <li property="article" typeof="ScholarlyArticle">
           <strong property="name"><span
property="articleSection">Opinion</span>:Trusting double-blind
peer-review</strong>,
           by <span property="author">Foo Bar</span>, p. <span
property="pagination">543-545</span>
         </li>
         <li> ... </li>
       </ul>
     </li>

or in microdata via the alternativeType property:

   <ul>
     <li itemprop="issuance" itemscope itemtype="Issuance">Volume
<span itemprop="issueVolume">7</span>,
       issue <span itemprop="issueNumber">6</span>
       <span itemprop="datePublished">2007</span>
       pages <span itemprop="pagination">543-633</span>
       <meta property="alternativeType" content="Collection">
       <ul>
         <li itemprop="article" itemscope itemtype="ScholarlyArticle">
           <strong itemprop="name"><span
itemprop="articleSection">Opinion</span>:Trusting double-blind
peer-review</strong>,
           by <span itemprop="author">Foo Bar</span>, p. <span
itemprop="pagination">543-545</span>
         </li>
         <li> ... </li>
       </ul>
     </li>

My concern on the complexity front is that the public-vocabs list has
seen some posts by people confused by the concept of applying multiple
types to a single entity, particularly in microdata. [1] [2] The
complexity of the multiple type approach seemed to generate resistance
on this list to the Holdings-as-Offers proposal on that front, even
though that was the intended design of Offer. Therefore I was wary of
stepping into those (hot) waters again.

In any case, I suppose we need to mark up what the current proposal
would look like for an Issuance that is not a collection, whether or
not Issuance itself is a subclass of Collection. The simplest approach
would probably be to use the existing CreativeWork properties directly
at the Issuance level. So, taking a recent comic book issue as an
example (I borrowed this issue from my spouse's collection for item in
hand cataloguing purposes) and trying to reflect how a comic book
would look if ComicIssue was a subclass of Issuance:

<div vocab="http://schema.org/" typeof="Periodical"><span
property="name">TRUE BLOOD</span>
<div property="about">TRUE BLOOD chronicles the backwoods Louisiana
town of Bon Temps... in a world where vampires have emerged from the
coffin and no longer need humans for their fix.</div>
<div property="publisher" typeof="Organization">Publisher: <span
property="name">IDW</span> (<a property="url"
href="http://www.idwpublishing.com">http://www.idwpublishing.com</a>)</div>
<ul>
  <li property="issuance" typeof="ComicIssue">Issue <span
property="issueNumber">13</span>
    <div property="author" typeof="Person">Author: <span
property="name">Michael McMillian</span></div>
    <div property="artist" typeof="Person">Art by: <span
property="name">Beni Lobel</span></div>
    <div property="colorist" typeof="Person">Colors by: <span
property="name">Esther Sanz</span></div>
    <div property="coverArtist" typeof="Person">Cover by: <span
property="name">Michael Gaydos</span></div>
    <div property="letterer" typeof="Person">Letters by: <span
property="name">Neil Uyetake</span></div>
    <div property="editor" typeof="Person">Edits by: <span
property="name">Beni Lobel</span></div>
    <div>Date published: <meta property="datePublished"
content="2013-05">May 2013</div>
  </li>
</ul>
</div>

I'll add this to the proposal as another example, with a note that
ComicIssue and several of its properties come from the Comics
proposal.

Aside: this version of the issue has cover "B"; there is also a cover
"A" version of the issue. While this is common in the domain of comics
as a way to drive up sales to collectors who simply must have all the
variants (heh), it is not limited to comics; records, books, and
popular magazines take this tack as well. [3] notes a magazine issue
that has 45 different covers (that thread has some interesting
thoughts about how to track these variations and why one might want to
provide a way to keep them separated; sadly while 45worlds seems to be
collecting a lot of data it does not (yet) publish it as structured
data, but maybe if we nail the Periodical proposal down it will be
easy for them to add it in...)

Perhaps CreativeWork therefore gets a "cover" property with a range of
ImageObject that can be repeated; the ImageObject's "name" property
would then enable the repeated variants to be distinguished?

> NB: I wouldn't have objection to use Collection's 'hasPart' to indicate that
> an issue has several components (and so that some issues are collections
> indeed). But it's also possible to make 'article' a sub-property' of
> hasPart. This would do the trick at the formal level, while keeping a
> property that has much 'business sense'. But of course this pattern has the
> disadvantage of needing (some) people (and machines) to look at the property
> definition.

Right, I'm in favour of "article" as a subproperty of "hasPart", this
would be consistent with having made "partOfIssuance" and
"partOfPeriodical" subproperties of "hasPart" as well, so I'll make
that change now. (Checking the Periodical proposal, I will call those
out as "subPropertyOf" rather than "subClassOf" to be RDFS-compliant).
I don't see any downside to this.

1. http://lists.w3.org/Archives/Public/public-vocabs/2013Aug/0004.html
2. http://lists.w3.org/Archives/Public/public-vocabs/2013Oct/0091.html
3. http://www.45worlds.com/topic/100062

Received on Thursday, 28 November 2013 15:40:18 UTC