- From: Dan Scott <denials@gmail.com>
- Date: Mon, 25 Nov 2013 09:34:39 -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>
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 14:35:14 UTC