- From: Shlomo Sanders <Shlomo.Sanders@exlibrisgroup.com>
- Date: Sun, 24 Nov 2013 07:31:48 +0000
- To: Dan Scott <denials@gmail.com>, Karen Coyle <kcoyle@kcoyle.net>
- CC: Niklas Lindstr?m <lindstream@gmail.com>, Owen Stephens <owen@ostephens.com>, "public-schemabibex@w3.org" <public-schemabibex@w3.org>
"Someone else (sorry, I forget who) mentioned that structured data is meant for consumption by machines, not humans, which seemed to be part of your concern about this separation of Periodical and Issue" That was me and I meant it just the opposite. Because it is meant for machine consumption we can separate into Periodical and Issue! Thanks, Shlomo Experience the all-new, singing and dancing interactive Primo brochure -----Original Message----- From: Dan Scott [mailto:denials@gmail.com] Sent: Friday, November 22, 2013 03:43 To: Karen Coyle Cc: Niklas Lindström; Owen Stephens; public-schemabibex@w3.org Subject: Why we want to have separate Periodical and (Periodical)Issu(e|ance) types On Thu, Nov 21, 2013 at 7:53 PM, Karen Coyle <kcoyle@kcoyle.net> wrote: <snip> > Actually, I was wondering about the utility of: > > [sketchy example begins] > > Periodical > name > issuance > volume > number > date > > vs. > > Periodical > name > volume > number > date Yes, you have mentioned this a number of times now. As I said on the call, we're working with structured data. One benefit lies in being able to define Periodical as an entity in and of itself, then refer to it from the separate issues, instead of repeating the core Periodical information in each instance of an issue (and worse, in each instance of an article in each instance of a Periodical). If you refer to two separate issues of the same periodical on the same page, and you haven't broken Periodical out separately from Issue, then you have to repeat all that core Periodical information with slightly different volume / number / date information. You could determine that they're the same Periodical by comparing their ISSN and name, I suppose, but that seems like a very twisted and artificial way to achieve what should be a very basic operation. Someone else (sorry, I forget who) mentioned that structured data is meant for consumption by machines, not humans, which seemed to be part of your concern about this separation of Periodical and Issue. I think you had also expressed concern about the use case of the professor trying to mark up their list of publications who might get confused by the idea of an Issue as separate from a Periodical; my response to that was, yes, there is some sympathy for manually-generated markup, but the bulk of schema.org is expected to be generated by applications--so whoever is enabling the publication of schema.org is going to be expected to spend some wrapping their heads around the schemas. And Corey noted that applications are likely to be able to do more with the resulting data if it has more structure than if it is simply flattened. For me, it often comes down to a very basic sniff test. Is the idea of an issue of a periodical something that normal humans would recognize as being separate from the periodical itself? I think that, yes, most humans would pretty easily recognize and distinguish "The New York Times" as something that is published regularly from "last Sunday's edition of The New York Times" as a particular instance of.that publication--separate, but connected to the idea of the publication in general. That, in and of itself, is enough justification for me to want to reflect those separate entities in schema.org.
Received on Sunday, 24 November 2013 07:32:17 UTC