RE: Why we want to have separate Periodical and (Periodical)Issu(e|ance) types

+1 on the example below

Thanks,
Shlomo

Experience the all-new, singing and dancing interactive Primo brochure<http://www.exlibrispublications.com/primo/>

From: Niklas Lindström [mailto:lindstream@gmail.com]
Sent: Monday, December 09, 2013 00:35
To: Dan Scott
Cc: Shlomo Sanders; Karen Coyle; Owen Stephens; public-schemabibex@w3.org
Subject: Re: Why we want to have separate Periodical and (Periodical)Issu(e|ance) types

Hi again,

Karen's minimal proposal just now also prompted me to remember this thread. This is something that's been on my mind for a while: that the essence of a Periodical/Issue division seems very much like our work/example case (both of which, as mentioned a while ago, seem very much like the CreativeWork equivalent of the ProductModel/Product pattern already present in schema.org<http://schema.org>).

I do believe there is much value in being able to describe a generalized entity (akin to a conceptual model or prototype), and then link more specific entities to that. I maintain this belief since I do not think these specific entities are "actually real" either - unless they represent tangible, physical exemplars. Thus, being able to reify various conceptually relevant generalizations is often very valuable. E.g. for avoiding copying of shared characteristics and the stale, redundant data which that commonly leads to (to mention one argument for normalization of data (though see also e.g. [1])).

(Of course, I only think this is good if there is conceptual understanding of a generalization in the domain in question. I do not believe in its use to optimize for engineering, if that would compromise the integrity of a domain notion. Certain patterns are naturally repeated, such as author and publisher for a sequence of works, etc.)

But also think that this case can be a richer extension upon a simple foundation. Thus I see much value in Karen's minimal proposal.

If we (go back and) solidify the optional capability of work/example, in the separate CreativeWork relationships proposal(s), we can then apply that here as well, for when it is needed. By doing so, we only need to ensure that this minimal basis is compatible with such a pattern.

I made a variant of Karen's periodical issue example to illustrate this suggestion:

    <div vocab="http://schema.org/" typeof="Periodical">
      <span property="name">Journal of Carbohydrate Chemistry</span>
      <span property="publisher">Taylor &amp; Francis Group</span><br />
      <strong>ISSN</strong><br/>
      <span property="issn">0732-8303 (Print),</span> <span property="issn">1532-2327 (Online)</span> <br/>
      <h3>List of Issues</h3>
      <div property="workExample" typeof="Periodical">
        - Volume <span property="volumeNumber">32 </span><span property="datePublished">2013</span><br/>
        Issue <span property="issueNumber">7</span> <span property="datePublished">2013</span>
        pages <span property="pagination">411-462</span><br/>
      </div>
    </div>

This of course hinges on one question: is there is a solid similarity between "periodical issues" and "work examples"?

Cheers,
Niklas

[1]: http://answers.semanticweb.com/questions/958/to-what-extent-should-data-be-normalized-for-use-on-the-semantic-web


On Mon, Nov 25, 2013 at 3:36 PM, Dan Scott <denials@gmail.com<mailto:denials@gmail.com>> wrote:
On Sun, Nov 24, 2013 at 2:31 AM, Shlomo Sanders
<Shlomo.Sanders@exlibrisgroup.com<mailto:Shlomo.Sanders@exlibrisgroup.com>> wrote:
> "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 for clearing up that mystery for me, Shlomo! I understood what
you meant during the call, I just did a very poor / confusing job of
paraphrasing it :)