- From: Dan Scott <denials@gmail.com>
- Date: Mon, 25 Nov 2013 11:09:56 -0500
- To: Owen Stephens <owen@ostephens.com>
- Cc: Ross Singer <ross.singer@talis.com>, Karen Coyle <kcoyle@kcoyle.net>, "public-schemabibex@w3.org" <public-schemabibex@w3.org>
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