Invalid ISSN ISSN that have wrong checksum (Help) Violations query:SELECT?item?value#?checksum ?last ?remainderWHERE{{?stps:P236?value.}UNION{?stpq:P236?value.}UNION{_:b1pr:P236?value.?stprov:wasDerivedFrom_:b1.}BIND(REPLACE(STR(?value),"-","")AS?nohyphen)FILTER((STRLEN(?nohyphen))=8)BIND(xsd:integer(REPLACE(SUBSTR(?nohyphen,8,1),"X","10"))AS?last)BIND((((((((xsd:integer(SUBSTR(?nohyphen,1,1)))*8)+((xsd:integer(SUBSTR(?nohyphen,2,1)))*7))+((xsd:integer(SUBSTR(?nohyphen,3,1)))*6))+((xsd:integer(SUBSTR(?nohyphen,4,1)))*5))+((xsd:integer(SUBSTR(?nohyphen,5,1)))*4))+((xsd:integer(SUBSTR(?nohyphen,6,1)))*3))+((xsd:integer(SUBSTR(?nohyphen,7,1)))*2)AS?checksum)BIND(?checksum-((FLOOR(?checksum/11))*11)AS?remainder)FILTER((?remainder+?last)!=11)FILTER((?remainder+?last)!=0)?item?p?st.} List of this constraint violations:Database reports/Complex constraint violations/P236#Invalid ISSN
Latest comment:5 years ago3 comments3 people in discussion
The unique constraint seems to be inappropriate here. It is unlikely that we will (typically) have distinct items for print vs online versions of a periodical, as the majority of the facts about both editions is the same - the main difference is that articles have two issued dates: first online and then in print. That difference is an attribute of the article, rather than of the periodical.John Vandenberg (talk)00:27, 25 February 2014 (UTC)Reply
11000 "single value" violations out of 28000 periodicals - all having two IDs: electronic + paper IDs. We need to suppress that constraint for now. Could be reinstated if there eventually exist a "one or two" constraint...LaddΩchat;)23:26, 15 March 2014 (UTC)Reply
I think the next step is to add a property for 'ISSN-L', which is constrained per the new (2007) ISO standard as having a single value for each journal. It will be very rare that we have two items with the same ISSN-L - so rare that the constraint exceptions list is sufficient to deal with them.
I have been thinking that perhaps the ISSNs should have a qualifier, instead of multiple properties, as it allows more flexibility.
I personally dont see the benefit in having distinct properties for electronic ISSN vs paper ISSN. Most of the time when people look up an ISSN, they dont care whether it is the ISSN or eISSN. The electronic version of the article (eISSN) and the digitised print version of the article (ISSN) are usually almost identical. However if someone puts together a well designed solution using multiple propertyies, I will support and help implement it.
Two issues to consider:
Periodicals can also haveCDROM ISSNs, which should probably be recorded on the main item for the journal. These are mostly given to conferences rather than journals, butPhysical Review Letters(Q2018386) does have a CDROM ISSN.
Periodicals can also have additional ISSNs (paper & electronic) for special editions, supplement, etc. These vary so much it is hard to say whether a rule can be written to say whether the special edition should a separate item or be part of the main item for the journal. Some supplements are very distinct works; others are only published once in place of a normal issue by the same team and most readers consider it to have been an odder-then-usual issue but not a separate work. However if they are a separate item, how do we link it to the main item, and should the special issue item have an ISSN-L property?
Latest comment:6 years ago1 comment1 person in discussion
This prop has 4 formatter URL and 7 third-party formatter URL. I understand these different databases include different journal lists, but I need some guidance on "which is better" (what is their respective coverage).
Latest comment:1 year ago2 comments2 people in discussion
Is there a way to denote a work that doesnot have an ISSN? For example the British journalThe Electrical Engineer(Q105221968) appears not to have one (the unrelated but roughly contemporaneous New YorkThe Electrical Engineerdoes). I set it to "no value" - is that right? Should there be a reference or "as of" qualifier?Inductiveload (talk)14:06, 3 February 2021 (UTC)Reply
