Re: E-ISSN?

On Mon, Nov 25, 2013 at 10:51 AM, Owen Stephens <owen@ostephens.com> wrote:
> I'd argue ISSN-L data isn't freely downloadable - before you can access it you have to register and state your intended use - which raises the possibility of a proposed use being denied.
> http://www.issn.org/2-24114-Request-for-downloading-the-ISSN-ISSN-L-table.php

Good point, Owen. It is far from linked open data! I had been
downloading it regularly for a while when it was first released, but
now I've submitted a request for an account with the intention of
launching a freely available web service based on the data. Let's see
where that goes.

In any case, I suppose we can treat it as data that will *most likely*
be available to schema.org processors (I have a hard time imagining
ISSN.org turning down a request from Google, Microsoft, or Yandex for
their 16MB zip file).

> However, I'm not sure this is a strong argument against simply repeating the issn property

+1

> On 25 Nov 2013, at 14:34, Dan Scott <denials@gmail.com> wrote:
>
>> As the ISSN-L data is freely downloadable and updated on a quarterly
>> basis, any system that aggregates and parses schema.org data will have
>> access to the ISSN-L table to determine linkages between print and
>> electronic versions of the same periodical.
>>
>> Therefore, I would recommend just using the http://schema.org/issn
>> property, repeated if necessary, for ISSN, eISSN, and ISSN-L. If a
>> system displays more than one ISSN for a given periodical and is
>> adding schema.org structured data, they could just repeat the issn
>> property as necessary.
>>
>> It would be worthwhile adding an explicit example the
>> http://schema.org/issn if we opt to go this route.
>>
>>
>> On Mon, Nov 25, 2013 at 3:59 AM, Owen Stephens <owen@ostephens.com> wrote:
>>> I think it is worth looking at what is out on the web already and consider
>>> what it would take to mark it up sensibly with schema.org for different
>>> approaches. For example from http://www.ajaonline.org/about
>>> "The American Journal of Archaeology (ISSN 0002-9114; E-ISSN 1939-828X),..."
>>>
>>> This seems perfectly readable and understandable to a human user who has
>>> some familiarity with journals. Given time I could dig out some examples of
>>> libraries having single records for print/electronic copies, and some
>>> publishers list both ISSNs on a single page for a journal.
>>>
>>> My concern would be that if we force these to split out into different
>>> statements of title + issn in schema.org we are going against the 'low
>>> barrier to implementation' that schema.org has aimed for in terms of data
>>> publishers, and possibly make the human readable representation of the data
>>> more awkward while making the machine readable version better/easier to
>>> consume. Ideally I'd like to spend some time digging out some examples of
>>> existing journal displays (not just from library catalogues) and seeing how
>>> they markup with different approaches, but unfortunately I'm not going to be
>>> able to do that this week.
>>>
>>> Owen
>>>
>>> Owen Stephens
>>> Owen Stephens Consulting
>>> Web: http://www.ostephens.com
>>> Email: owen@ostephens.com
>>> Telephone: 0121 288 6936
>>>
>>> On 24 Nov 2013, at 15:12, Ross Singer <ross.singer@talis.com> wrote:
>>>
>>> I'm not deeply emotionally invested which decision is made, but it seems
>>> like just having "ISSN" will be enough. As we've established, there's really
>>> no such thing as an eissn (as a distinct property) and while issn-l is, I'd
>>> be more interested to see how it's useful (in a schema context) before we
>>> accommodate it.
>>>
>>> I guess I already hate dealing having to look for issn and eissn properties
>>> when parsing serials data, adding another place to look just seems
>>> unnecessarily complicated for the consumer.
>>>
>>> That said, if a compelling argument can be made, I'm not going to argue
>>> against it.
>>>
>>> -Ross.
>>> On Nov 24, 2013 9:42 AM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
>>>>
>>>>
>>>>
>>>> On 11/23/13 3:44 PM, Owen Stephens wrote:
>>>>>
>>>>> I think the ISSN registry does indeed treat these as the 'ISSN' - so the
>>>>> eISSN isn't a different kind of ISSN but just a different label for the
>>>>> ISSN applied to an electronic publication.
>>>>>
>>>>> However there is a lot of common practice that treats the concept of the
>>>>> journal 'title' as being something apart from the actual instantiations
>>>>> and so groups the print and electronic versions together, thus needing
>>>>> to differentiate through the use of the 'e' prefix for one of the ISSNs.
>>>>> Two systems I'm involved in (KB+ and GOKb) do this I'm afraid to say,
>>>>> and it is common practice in other 'knowledgebases' (SFX, SS360 etc.) as
>>>>> well as being pretty much baked into the KBart guidelines
>>>>> (http://www.uksg.org/kbart/s5/guidelines/data_field_labels).
>>>>>
>>>>> The ISSN-L is, as you say, an ISSN used to link things together but as
>>>>> far as I understand it the ISSN-L is simple one of the existing ISSNs
>>>>> for the title (not necessarily the ISSN for the print version, although
>>>>> it commonly is) and is not intended as a separate identifier but simply
>>>>> that one of the identifiers plays an additional role - although I'm not
>>>>> sure this isn't just messing about with the semantics to be honest, and
>>>>> in any case I don't think really helps us.
>>>>
>>>>
>>>> Here's what the page [1] says:
>>>>
>>>> *****
>>>>
>>>> Do publishers need to indicate when they are using ISSN-L as opposed to an
>>>> ISSN?
>>>>
>>>> Yes, in order for the ISSN-L to work effectively, publishers need to
>>>> clearly indicate when they are using an ISSN-L as opposed to an ISSN.
>>>>
>>>> The ISO standard recommendations for printing and displaying ISSN-L are as
>>>> follows: “the linking ISSN shall be clearly distinguished as such by use of
>>>> the label ISSN-L. In such cases, the label ISSN-L shall be written in
>>>> uppercase and a space shall precede the 8 digits of the linking ISSN.
>>>> Example : ISSN-L 0251-1479”.
>>>>
>>>> *****
>>>>
>>>> It looks like LC has gone through their existing serial file and
>>>> automagically created the ISSN-L subfield in the 022 (these are from old
>>>> journals):
>>>>
>>>> 022     __ |a 0096-5340 |l 0096-5340
>>>> 022     __ |a 0006-3541 |l 0006-3541
>>>>
>>>> I can find some usage by searching on "ISSN-L":
>>>>
>>>> "Print edition: ISSN-L 2247 - 9880. Online edition: ISSN 2247 - 9880"
>>>>
>>>> "Editor-in-Chief:Dr. Ecaterina Patrascu
>>>> Frequency:Monthly
>>>> ISSN 2286-4822
>>>> ISSN-L 2286-4822"
>>>>
>>>> So it *is* being used - I was wrong about that.
>>>>
>>>> The question, though, is whether we need an actual property for the
>>>> ISSN-L, or whether we can put this and the eISSN into an ISSN field. And if
>>>> the latter, do we leave/put the "ISSN-L" or "eISSN" in the string value for
>>>> the property?
>>>>
>>>> As I said to Diane, this gets us back to the "non-URI" identifiers
>>>> question. How far do we want to go to accommodate these? What use cases
>>>> exist that would help us decide?
>>>>
>>>> kc
>>>>
>>>> [1] http://www.issn.org/2-22637-What-is-an-ISSN-L.php
>>>>
>>>>
>>>>
>>>>>
>>>>> To address the questions:
>>>>> The concept of the 'eISSN' is useful as long as people continue to
>>>>> represent the print and electronic versions as part of the same 'record'
>>>>> - and I don't see this changing at the moment
>>>>> I'm not confident that we can ignore the ISSN-L - this is a relatively
>>>>> recent concept and my instinct is use will grow over the next few years
>>>>> - again it is something that has been discussed in both the GOKb and KB+
>>>>> projects although no specific use yet I think there will be once we have
>>>>> the data available.
>>>>>
>>>>> Owen
>>>>>
>>>>>
>>>>> Owen Stephens
>>>>> Owen Stephens Consulting
>>>>> Web: http://www.ostephens.com
>>>>> Email: owen@ostephens.com <mailto:owen@ostephens.com>
>>>>>
>>>>> Telephone: 0121 288 6936
>>>>>
>>>>> On 22 Nov 2013, at 23:10, Karen Coyle <kcoyle@KCOYLE.NET
>>>>> <mailto:kcoyle@KCOYLE.NET>> wrote:
>>>>>
>>>>>> One of the examples I added includes the E-ISSN. I have mixed feelings
>>>>>> about this, but I suspect it is quite common in metadata. (It seems to
>>>>>> me that it should be an ISSN attached to an electronic publication,
>>>>>> not a different kind of ISSN... oh well.) There is also the ISSN-L,
>>>>>> which fortunately does not seem to be referred to much, so I hope we
>>>>>> can ignore it.
>>>>>>
>>>>>> If you haven't run into ISSN-L, it is the ISSN of the print copy, and
>>>>>> is presumably used to gather the various formats (E, print, whatever)
>>>>>> together. The "L" stands for "linking." From the ISSN agency page:
>>>>>>
>>>>>> ISSN-L 0264-2875
>>>>>>           Printed version: Dance research = ISSN 0264-2875
>>>>>>           Online version: Dance research (Online) = ISSN 1750-0095
>>>>>>
>>>>>> If you know of a growing use of these, please speak up. I haven't run
>>>>>> into them, but I'm not watching any serials databases carefully. Also,
>>>>>> if E-ISSNs are falling out of use, then we can skip those. Anyone?
>>>>>>
>>>>>> kc
>>>>>> --
>>>>>> Karen Coyle
>>>>>> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>>>>>> m: 1-510-435-8234
>>>>>> skype: kcoylenet
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Karen Coyle
>>>> kcoyle@kcoyle.net http://kcoyle.net
>>>> m: 1-510-435-8234
>>>> skype: kcoylenet
>>>>
>>>
>>>
>

Received on Monday, 25 November 2013 16:10:32 UTC