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

Niklas -- that is an interesting take on the FRBR-ish 
work(abstraction)/exemplar(or instance or manifestation). If work is the 
abstraction, though, I don't think the ISSN can be applied to it, and we 
end up with the question of what to do when titles change (new work?). 
But if you think of work as the ongoing concept of the periodical and 
exemplar as the articles it contains...

I keep coming back to the shift made a while ago in libraries to no 
longer use the term "periodical" but to speak of "ongoing resources" - 
it's an ugly phrase, not understood by the world at large, but I think 
the concept is the right one. There's something that stays the same over 
time (probably represented by the periodical title), that produces units 
(volumes, numbers) that contain the actual content (articles). So 
depending on your point of view you have "workness" at multiple levels 
(periodical, issue, article). (I see volume as less a work than a 
publication pattern, and whether or not you see issue as a work depends 
on where you stand on aggregates in the FRBR sense. Special issues with 
a single topic generally = book of essays, while non-special issues are 
less so.)

kc

On 12/8/13, 2:35 PM, Niklas Lindström wrote:
> 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 :)
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet

Received on Monday, 9 December 2013 15:28:46 UTC