Re: journal article for next call?

Hi Dan,

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


Never. As long as there is one issue which is not a collection, it is wrong to declare that the class Issue is generally a sub-class of Collection.

As for the complexity of the dual typing for the case of issues that happen to be collection. Yeah, I agree that this is not optimal. On the other hand, this can't be used as a motivation for including false axioms on the ontology.  Period.

If you want one type, then you'd have to create one class Issue-that-is-a-collection, both a subclass of Issue  and Collection.

But in fact I have doubts whether typing resources as Collection brings value anyway, with the current proposal for Collection. What does the definition of Collection tell us? That we can use hasPart properties? Well, we can just ask to activate hasPart on Thing (which it probably is) and then we have what we want.
And after all, your dual typing argument would apply to any class in schema.org, which instances can have parts. Which I expect concerns many classes.

Antoine


> 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 Friday, 29 November 2013 03:08:07 UTC