Re: journal article for next call?

Hi Karen,

On Thu, Nov 21, 2013 at 9:51 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:

> On 11/21/13 12:12 PM, Owen Stephens wrote:
>
>  I'd argue that the issue is a creative work - especially if we are
>> talking about issues of less "academic" periodicals - for example the
>> January issue of Wired is surely a creative work in it's own right?
>>
>
> Owen, I wasn't aware that the proposal said otherwise, but perhaps I
> haven't fully understood the implications. To make things practical, it
> seems that the journal/periodical, the issue, and all of the articles must
> be creative works - in part because, well, what else could they be? There
> are also individual issues that have a coherent theme and that are
> essentially anthologies issued by a periodical publisher. (Note, and here
> we get into the territory currently occupied by the folks working on Comics
> in schema.org [1]. They already have a proposed PeriodicalSeries and
> PeriodicalIssue, and it's structured quite differently from what we have
> been discussing.)


Ah, that was a long way back in my mind today! :) Thanks for bringing it to
light in relation to this! I really think we should consider merging these
proposals somehow. How different are these "world views", really? Might a
scruffy union make things simpler for us all? I really hope so.

(For that matter, I think Series, TVSeries and TVSeason also have
interesting characteristics that might be shared at some level with the
notions we are working with here. At least by using Collection as a common
superclass.)


>
>
>> In terms of pagination going into CreativeWork I don't feel strongly -
>> there are plenty of properties on CreativeWork that don't apply to all
>> more specific types under CreativeWork so I don't see a particular
>> problem there if the wider community is OK with it. It would apply to
>> book chapters if there is markup for those in the future which would be
>> nice.
>>
>
>
> Right now in schema, "numberOfPages" is in /Book, and it has a range of
> Integer. (that tells me right there that the /Book type was developed with
> publishers in mind). This means that there is no designated place for what
> libraries call "pagination" which is that odd bit that can look like "xii,
> 356p." (Publisher data provides the number of pages, and it is the actual
> physical number of pages in the book, not the pattern of printed
> pagination.) At one point I argued for the addition of something broader in
> CreativeWork that would include (somehow) the extent of any creative work
> -- otherwise, these have to be defined for each CW type -- sound
> recordings, movies, book chapters, YouTube streamed videas.... ad nauseum.
> I don't know what the solution is, but I think we can see the problem. In
> any case, adding pagination in a way that it only can be used with
> periodicals does not make sense, since it is also needed for books and book
> chapters. (Plus, although we may not want to go there, some A&I services
> include number of pages in their metadata, which was used during the
> photocopy days of article ILL. Presumably this can be inherited from
> CreativeWork.)


These are interesting questions. There is the possibility, which DanBri
also recently mentioned on public-vocabs [2], of linking properties to
their super-properties (using rdfs:subPropertyOf). I think a generic extent
property could indeed be useful (with an undefined range, or a simple range
like Text), from which specific properties such as numberOfPages and
duration can be derived. That would clearly group them together, which may
also be navigable through the documentation pages in the future (something
Dan hints at).


>
>> Finally I can't say I'm keen on Issuance although it's not something I'd
>> lose sleep over. Perhaps something like 'PublicationIssue' might work?
>>
>
> I, too, have some problems with "Issuance," but it's mainly that I don't
> see a new type as being necessary to carry those properties. I'd like to
> see an example where adding volume and issue to Periodical causes problems.
> Do we anticipate that there will be non-periodicals that use this?
>

Do you mean that the Periodical class may be used to describe both the
Periodical at large, as well as individual issues thereof? I'm can imagine
using it to cover both notions if merely omitting some properties for the
more general periodical would do the trick (just as with various general
and specific CreativeWork notions).

(Btw., I just realized I wrote Publication instead of Periodical in quite a
few places in my last mail. Just drifted since 'PublicationIssue' reads
much better than 'PeriodicalIssue'..)

Cheers,
Niklas

[2]: http://lists.w3.org/Archives/Public/public-vocabs/2013Oct/0224.html



>
> kc
>
> [1] http://www.w3.org/wiki/WebSchemas/PeriodicalsComics
>
>
>
>> Owen
>>
>> Owen Stephens
>> Owen Stephens Consulting
>> Web: http://www.ostephens.com
>> Email: owen@ostephens.com <mailto:owen@ostephens.com>
>>
>> Telephone: 0121 288 6936
>>
>> On 21 Nov 2013, at 14:30, Dan Scott <denials@gmail.com
>> <mailto:denials@gmail.com>> wrote:
>>
>>  On Thu, Nov 21, 2013 at 5:09 AM, Owen Stephens <owen@ostephens.com
>>> <mailto:owen@ostephens.com>> wrote:
>>>
>>>> Thanks for this Dan. I'm afraid I can't make the call today but I had a
>>>> question - why is 'Issuance' under 'Intangible' and not 'CreativeWork'?
>>>>
>>>
>>> Great question Owen!
>>>
>>> My rationale was that I was hoping to avoid the mass of properties you
>>> inherit from CreativeWork, with the goal of guiding users of these
>>> types towards consistent usage patterns (that is to say, keeping data
>>> about the Periodical at the Periodical level, and data about the
>>> Article at the Article level, and keeping a bare minimum of data at
>>> the Issuance level). Of the CreativeWork properties, "datePublished"
>>> was the most obviously useful one.
>>>
>>> Last night I was musing that "editor" may also come into play at the
>>> level of a given Issuance and probably should be drafted into Issuance
>>> as well; but the rest of the properties seem more appropriate to be
>>> applied to the Periodical as a whole, or to the individual Articles
>>> within the given Issuance.
>>>
>>> I thought the Series / Episode pattern might be instructive for our
>>> Periodical / Issuance. Episode inherits from CreativeWork, but the
>>> more I think about it, the more I'm convinced that an Episode really
>>> is a standalone CreativeWork, whereas a given issue of a periodical is
>>> generally not much more than a collection of individual CreativeWorks.
>>> To be sure, the editor of a given issue does put their stamp on the
>>> end result, puts in a tremendous amount of labour coordinating efforts
>>> of the various contributors, and often guides the subject matter
>>> chosen for that issue, but it seems like a stretch to call the issue a
>>> CreativeWork.
>>>
>>> However, if we do opt to go with the "Issuance inherits from
>>> CreativeWork" route, then I would argue that "pagination" should
>>> simply be added to CreativeWork. (Yes, this leads to movies or
>>> sculptures with paginations... ah well, maybe it's a flip-book
>>> animation, or a sculpture made out of numbered pieces of paper!)
>>>
>>> One other note on naming: I went with "Issuance" rather than "Issue"
>>> to avoid claiming the namespace that might also be desired by bug
>>> trackers or international policy metadata. Those in a position of
>>> marking up individual issues of a periodical seem likely to be able to
>>> deal with "Issuance" as a term.
>>>
>>> Dan
>>>
>>
>>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet
>
>