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
).

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> wrote:

> On Sun, Nov 24, 2013 at 2:31 AM, Shlomo Sanders
> <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 :)
>