support Standards item type

[mmoole]

First lets recap whats already been on the forums regarding the standards item type: http://forums.zotero.org/discussion/2914/ btw the link to the IEE manual didn't work for me, but this one works: https://development.standards.ieee.org/myproject/Public/mytools/draft/styleman.pdf see chapter 18.2

Although standards have a lot of specific information, for citing we only need the most important things. So lets just start with the most important fields on the top:

• designator for the body org in short form - i.e. ISO/IEC/DIN/ but this can also be a combination like DIN EN ISO.…
• designator for the specific standard - usually a number, i.e. 10646
• number of the part if applicable, i.e. -4 (when citing ISO/IEC 7498-4)
• year - this is also often followed with a colon directly by the number, i.e. 10646:2003 well, it could also make sense to include all these four into one field. This might make it much easier!?
• title - the title of the standard
• title of the standards part, if applicable, i.e. Part 4: Management framework
• long form of the body organization/issuing authority - could also be a company name
• pages
• ISBN number if applicable
• language
• issuing workgroup
• short title
• place
• country
• abstract
• URL

maybe:

• ICS class - for example 01.040.31; 31.260 - see for info: http://en.wikipedia.org/wiki/International_Classification_for_Standards
• DOI
• type or genre: specification, test method, procedure, guide etc…

i hope i didn't miss a lot, so feel free to comment and make more suggestions :-)

[dwl-sdca]

When adding the engineering code type please don't make it too restrictive. There are other standards bodies, the NFPA fire and life codes come to mind. Various levels of government in the USA have their own sets of codes that may be more or less strict.

[rmzelle]

@dwl-sdca, do you have any examples of how such codes are cited in the literature?

[bdarcus]

Technically, isn't the document type here a "specification"; rather than a "standard"?

[dwl-sdca]

Not at hand but I'll find and send you examples.

David

David W. Lawrence, PhD, MPH, Director Center for Injury Prevention Policy and Practice San Diego State University, School of Public Health 6475 Alvarado Road, Suite 105 San Diego, CA 92120 USAdavid.lawrence@sdsu.edu V 619 594 1994 F 619 594 1995 Skype: DWL-SDCAwww.CIPPP.org -- www.SafetyLit.org

On Tue, Nov 6, 2012 at 12:14 PM, Rintze M. Zelle notifications@github.comwrote:

@dwl-sdca https://github.com/dwl-sdca, do you have any examples of how such codes are cited in the literature?

— Reply to this email directly or view it on GitHubhttps://github.com/ajlyon/zotero-bits/issues/52#issuecomment-10125874.

[AndrewNOConnor]

+1 for this feature and the discussion on the forum. One of the biggest difficulties is having the reference display correctly, as many standards have a more common method, eg. ISO standards almost always have a colon than the year of publication, where as UK Def Stans have dashes between the parts being referenced. So maybe a field which simply allows the user to type how they want it to be displayed.

If possible could the references be imported from a website like: http://www.everyspec.com. This may provide some consistency to the many different types of standards.

[AndrewNOConnor]

Sorry as an additional comment, its important that the status of the standard be included. These include: Draft / Current / Interim / Superseded / Cancelled. There are numerous times which draft or cancelled standards are used in literature.

[bdarcus]

Has anyone here answered my question above? I really don't think a "standard" type makes sense; what gets standardized, and cited, are specifications.

[adam3smith]

isn't specification more confusing than it helps, though? People refer to the standard specifications as the "Standard" (what else would the standard be) just the way they refer to patent specifications as the "Patent."

[karnesky]

@bdarcus Not sure what prompted the "bump", so I may be missing something. This seems to be a bit of a semantic argument. The MARC Genre Term here would be "standard or specification".

I understand where you're coming from, but think the broader/parent term may be defensible. Some standards bodies differentiate a specification from, e.g., a test method (that you may also want to cite). See, for example, https://en.wikipedia.org/wiki/ASTM_International

[bdarcus]

It's a semantic discussion, but also one about levels of abstraction. I guess you guys are saying they're two words for the same thing. I'm saying they're not, though admittedly not with great certainty.

[karnesky]

I actually agree they're different things, though different standard bodies are not consistent in differentiating them. Many bodies release documents that they do not consider to be "specifications", but are typically cited the same way as a specification produced by the standards body.

It is worth working out abstraction, still. But I probably see it a bit flatter than you: do we need @mmoole's enumeration of the "type or genre" field? It doesn't seem to be in the MARC/MODS model & (probably) doesn't impact citations. But some bodies do record this bit of info.

[ewa]

Has anything happened recently on this (beyond Dan Forsberg's file here: http://forsberg.fi/zotero.html)

[joelotz]

I agree, has anything happened on this discussion?

[adam3smith]

The whole point of a ticket is to allow people to see if there's any progress. There hasn't been.

[mxa]

I'd like to see progress here. 5 years later.

[rmzelle]

@mxa, it would help us if you and other interested parties could give us links to the relevant sections of popular style guides on the topic of standards, so we can make an inventory of what types of fields would be required to support this kind of item type.

[jasonzou]

Here is an example in APA 6th ed. http://libraryguides.vu.edu.au/apa-referencing/patents-and-standards Standard code/number is formatted differently.

[ewa]

Several examples are provided here: http://guides.library.uoit.ca/standards/citing , with references to their sources.

• IEEE: https://development.standards.ieee.org/myproject/Public/mytools/draft/styleman.pdf#page=35
• ASME: http://libraryguides.missouri.edu/mae/asmecitation

[ewa]

In practice, I generally use the techreport BibTeX item type. So this specification produces the BibTeX (exported from Zotero) below.

@techreport{36785V2V,
    title = {36.785: {{V2V Services}} Based on {{LTE}} Sidelink; {{User Equipment}} ({{UE}}) Radio Transmission and Reception},
    timestamp = {2016-06-15T15:53:26Z},
    number = {36.785},
    institution = {3GPP},
}

The main challenges here are:

• Standards almost never seem to have a designated author, and if they do, that's not usually what you want to reference them by. So that throws off lots of styles which at best complain about missing authors. That leads to throwing off how references are sorted. One "solution" is to list the issuing group / standards body as the author, but that ends up being redundant if you provide that information anywhere else.
• Standards are so often referred to by their number (or other designator) that you really want it to be the cross-reference key (unless you're just using numbered refs), and it should be the first part of the "title" in the bibliography. But incorporating it into the "title" field is kind of an ugly hack and gets redundant if you also include in a structured field.
• There are lots of sub-types and extra fields that capture useful information but may not always need to be displayed.

If I could have anything I wanted, the reference data would be something like this:

@Specification{36.785V2V,
  title = {{V2V} Services Based on {LTE} Sidelink; User Equipment({UE}) Radio Transmission and Reception},
  title_long = {3rd Generation Partnership Project; Technical Specification Group Radion Access Network; {V2V} Services Based on {LTE} Sidelink; User Equipment({UE}) Radio Transmission and Reception (Release 14)},
  subtype = {TR},
  number = {36.785},
  version = {V14.0.0},    [comment:  Maybe this should be 14.0.0 instead?]
  issuer = {{3GPP}},
  issuer_long = {3rd Generation Partnership Project},
  sub_issuer = {TSG RAN},
  sub_issuer_long = {Technical Specification Group Radio Access Network},
  special:3gpp:date_rev = {2016-10},
  special:3gpp:release = {14}
}

A natural sort key (in places where we'd typically use the author) would be 3GPP TR 36.785, and a reasonable rendering (following the ASME guide) would be

2016, 3GPP TR 36.785: Vehicle to Vehicle (V2V) services based on LTE sidelink; User Equipment (UE) radio transmission and reception.

I could probably be convinced that, even though the citation guides don't say anything about it, a version should be considered part of the specification number, giving something like:

2016, 3GPP TR 36.785 V14.0.0: Vehicle to Vehicle (V2V) services based on LTE sidelink; User Equipment (UE) radio transmission and reception.

[ewa]

I realize those aren't complete answers, but maybe they're helpful @rmzelle. 3GPP makes puts out the weirdest, hardest-to-reference standards I deal with, so if a solution works for them it's off to a good start.

[WarthogARJ]

I've been asking for this feature on the Zotero forum since 2006 as well.

I like @ewa format idea. "Sub-type" is very important, it can be used to refer to a Draft, or to a Recommended Practice as well.

Another comment is that the US standards environment is the exception and not the rule in terms of international practice.

Most countries have in effect STANDARDIZED their standards, and don't have the many 1,000's that the US has. Look at the entire European Community for example, they merged their national standards bodies into one central body: CEN (issues EN standards). It's not just the European Union, but contains other linked countries like Switzerland. Many countries outside the EU import EN standards: this happens in South Africa and Australia for example. CEN has formal links with a lot of the major non-EU standards bodies, like Japan. They only have an informal relatonship with ANSI (they use this exact term).

And many ISO standards are based on EN standards, in fact CEN and ISO have close ties, understandable since ISO is European based.

The US doesn't really have a central body that issues/controls standards. ANSI is the closest you get, but it doesn't actually draft its own standards.

Anyways, I would suggest that in terms of international coverage, that Zotero ensures its eventual standard type to be a close fit to ISO and CEN standards. That will still fit the major US standards organizations. I think trying to make it fit to the (many 1,000's of) minor US standards issueing bodies is counter-productive: it's better to keep up the pressure on them to merge into a more uniform output.

This has already happened to a large extent with the US military MIL-SPEC's. They decided it was costing too much to maintain the huge number they had, and have decided to cut them back to the few they really need and use civilian specs instead.

[ewa]

I looked into adding a "specification" type on my own local branch of Zotero, and concluded that it was a bigger PITA than expected: The definition of the item <-> itemType <-> field(s) <-> value(s) relation sseems to be spread over a bunch of different files, and adding a new itemType breaks synchronization with the server.

So ... is there a not-super-painful way for a user/developer who isn't a Zotero expert to prototype out an implementation before suggesting it as a change to Zotero proper? Or is this just one of those "leave it to the experts" things?

[adam3smith]

It's fairly involved for a non-expert and it completely breaks your copy of Zotero for sync. What's your interest in prototyping this on a fork? It's not going to make this move any faster -- for that, a simple list of fields and mapping to CSL (and other Zotero fields) with mutual agreement from several folks knowledgeable on referencing standards and links to citation examples (much of which is already present in this thread here). Translating this into database and display changes is indeed a job for the developers, but the real expertise needed here is substantive.

[ewa]

I suppose that's true. My interest in prototyping it is just the usual - I'd like to use it. If it were easy, I'd set up something for my own use, and maybe learn a few things that might inform what gets implemented for real later. But it looks to be not so easy.

[adam3smith]

Setting this up to show a couple of extra fields and a new item type is fairly easy, but as I say, that breaks a lot of other things, some over which you have no control (like sync), so I wouldn't think it's worth it. It also likely would not work well with updates and not be compatible with the actually implemented solution later on, so if this is intended for actual work, I'd advise against it.

[coldacid]

Something to make note of is that some documents that could fall under this type may be part of different standards series -- for example, RFCs 2119 and 8174 are also (jointly) BCP 14 -- and all these series identifiers may need to be included in a citation for the standards.

Looking at text citations for these two RFCs as provided by the RFC editor website, we see: (1, 2)

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

There also are plenty of standards out there which are shared between standards series published by different institutions without a joint issue sharing the same identifying number in each series; off the top of my head I can think of Office Open XML (ECMA-376, ISO/IEC 29500) and there are certainly others.

[redleafnew]

hope it finish soon

[bdarcus]

Just wanted to try to make sense of this all, and address my earlier concerns. This link that someone added is, I think, helpful to do that.

Based on that, and what I see in this thread; it's possible we actually don't need any new fields, because we're still dealing with titles, document numbers, URLs, (corporate) authors, etc.

So why the new type for CSL?

Because, as someone here documented, it's common that rendering for these differ from the default "document" type.

My suggestion: let's just accept this, and add a single change to the schema and specification: a new "standard" type.

We can then make clear in the specification the relation to "specification."

Does that make sense?

[denismaier]

Yes, absolutely. If we'll realize there's a need for more fields it will be possible to address this in later release.

[lingr7]

kb:style standards [Zotero Documentation]

I did n’t find a solution, and I did n’t have the knowledge and ability to provide help on the zotero-wiki, but I think it is often cited that the standard will be in BibTex, which introduces a BibTex solution using python for the 3GPP standard entry mentioned upstairs. 3gpp-citations · PyPI martisak/3gpp-citations: Generate .bib-file for 3GPP specifications

[WarthogARJ]

I was in on this quite early, and after reading through the comments, I think it's important to not be too restrrictive on what items you list as a "Standard".

And I think it might be best to call it a "Specification" in a generic sense. I'd argue that all Standards are Specifications, but not the obverse.

Speaking as an engineer, we use a large range from legally required "specifications"/"standards" to "guidelines" and "recommended procedures". And depending on your location, what you use might be a legal requirement for you, but is just a guideline in another country.

And standards can be Drafts, for Review, Current, or Withrawn/Replaced.

So my point is that to be really useful, you need to be able to be pretty flexible about what you put into the various fields: it cannot all be dumped into "Extra".

And there are too many standards bodies to have templates for all "Standards"

So forgive me if I'm saying what's not practical, or been said already, but I think the main structure should be: Title: Issueing Organisation: Reference number: Year Issued: (or valid from, whichever is relevant) Type: this should be free form, where you can type insomething like "Guideline", "Recommended Practice", "Public Review", "Working Draft", "Specification" etc etc

And then a bunch of fields to try to allow entry of all the other stuff, but I think the first ones are most important.

[bwiernik]

The standard item type is already implemented in CSL 1.0.2. There is no further need for justification.

[redleafnew]

I would like to know which beta version will support standard item type?

[dstillman]

@bwiernik: Can you summarize the fields and CSL mappings required?

[bwiernik]

Sure

@rmzelle @adam3smith I'd appreciate your input here. Engineering standards aren't an area I'm that familiar with

[redleafnew]

Will the standard item type be supported in zotero recently ? Thanks.

[redleafnew]

Is there any progress for the standard item type?

[dstillman]

I can add this as soon as I'm given the final list of fields and CSL mappings.

[bwiernik]

@redleafnew What are the fields you'd expect for a Standard item?

@adam3smith @bdarcus Do we know anyone who works with standards that could help with fields?

[redleafnew]

I think the fields in JurismM is reasonable: Title, Author, Number, Publisher, Version, Date, Language. Short Titel, URL, Accessed, Archive, Loc. in Archive, Library Catalog, Call Number， Rights, Extra, Data Added, Modified. Besides, Pages and Publisher-place are needed.

[linjaaho]

@adam3smith @bdarcus Do we know anyone who works with standards that could help with fields?

I work with international electrotechnical standardization (IEC), as the convenor of two groups preparing the standards (TC 1 MT 100 and PC 128 WG 2). ISO and EN standards are very familiar too, as well as American SAE-standards. What kind of assistance you do need?

[linjaaho]

@dstillman @adam3smith @redleafnew @bwiernik When citing EN/ISO/IEC/SAE standards, the following fields are (in my opinion) to be included (from here) :

• authority (IEC, SAE, IEEE, etc.)
• language
• title
• URL
• edition
• issued
• number
• page

For instance, with IEC: IEC 60364-7-722:2018 ( https://webstore.iec.ch/publication/29958 ):

• authority: IEC
• language: en
• title: Low-voltage electrical installations - Part 7-722: Requirements for special installations or locations - Supplies for electric vehicles
• URL: https://webstore.iec.ch/publication/29958
• edition: 2.0
• issued 2018-09-21
• number: IEC 60364-7-722:2018
• page: the page(s) to be referenced

These fields are adequate when citing the standards with APA (1, 2) or IEEE.

[adam3smith]

Thanks both -- so going by the lists above, a couple of remaining questions and some comments:

1. do we need publisher and authority or just one of the two? And if the latter, which is better? (I'd be weakly inclined towards authority). In either case, how should this field be called in Zotero?
2. Do we need publisher-place as suggested by @redleafnew above? (I don't currently think so, but OK if we do)
3. Do we actually need a page field? Specifying a page range cited would be via locator and those are available anyway?
4. We'll definitely want genre (I imagine we'd keep this Zotero "type") as described in some of the earlier posts
5. I think version makes more sense than edition as suggested by @linjaaho

We'll definitely want DOI -- I'm sure there are already standards with DOI, and it's going to become more common.

So my current proposal would be:

• Standard fields: Title, Author/Contributor, Date, Language. Short Titel, URL, DOI, Accessed, Archive, Loc. in Archive, Library Catalog, Call Number, Rights, Extra, Data Added, Modified
• Issuer (CSL: authority (IEC, SAE, IEEE, etc.))
• Publisher and Place of Publication (see below)
• Standard number (CSL: number)
• Version
• Type (CSL: genre)

[redleafnew]

I think page, publisher-place and publisher is necessary, We are asked to cite them in Information and documentation—Rules for bibliographic references and citations to information resources (GB/T 7714-2015) https://wjk.usst.edu.cn/2020/0523/c10336a220878/page.htm

[adam3smith]

Could you give an example of what they would be? I can't get the Chinese to translate well enough & the only example with "standard" in English refers to a book.

[redleafnew]

National Information and Literature Standardization Technical Committee. Bibliography: Part 4: Non book materials: GB/T 792.4-2009 [S]. Beijing: China Standards Press, 2010: 3 where National Information and Literature Standardization Technical Committee--Author Bibliography: Part 4: Non book materials--Title GB/T 792.4-2009--Number [S]--item type Beijing--Publisher palace China Standards Press--Publisher 2010--Year 3--Page

[adam3smith]

OK, so that's clear on Publisher & Publisher-place, so let's include those, but for page, this seems like a locator rather than a page range? Recall that the definition of CSL page (and the corresponding Zotero Pages) is : "Range of pages the item (e.g. a journal article) covers in a container (e.g. a journal issue)"

[dstillman]

To clarify, this is where the page locator is set:

https://www.zotero.org/support/word_processor_plugin_usage#customizing_cites

[redleafnew]

I think it is pages, in another example it is 2-3

[adam3smith]

Locators can be ranges as well. pages would cover the entire page range of a publication contained in a container publication. That really doesn't appear to be the case here?