- From: Dan Scott <denials@gmail.com>
- Date: Thu, 28 Nov 2013 10:39:49 -0500
- To: Antoine Isaac <aisaac@few.vu.nl>
- Cc: "public-schemabibex@w3.org" <public-schemabibex@w3.org>
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