support Standards item type #52
Comments
|
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. |
|
@dwl-sdca, do you have any examples of how such codes are cited in the literature? |
|
Technically, isn't the document type here a "specification"; rather than a "standard"? |
|
Not at hand but I'll find and send you examples. David David W. Lawrence, PhD, MPH, Director On Tue, Nov 6, 2012 at 12:14 PM, Rintze M. Zelle
|
|
+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. |
|
Sorry as an additional comment, its important that the status of the standard be included. These include: |
|
Has anyone here answered my question above? I really don't think a "standard" type makes sense; what gets standardized, and cited, are specifications. |
|
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." |
|
@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 |
|
It's a semantic discussion, but also one about levels of abstraction. I |
|
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. |
|
Has anything happened recently on this (beyond Dan Forsberg's file here: http://forsberg.fi/zotero.html) |
|
I agree, has anything happened on this discussion? |
|
The whole point of a ticket is to allow people to see if there's any progress. There hasn't been. |
|
I'd like to see progress here. 5 years later. |
|
@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. |
|
Here is an example in APA 6th ed. http://libraryguides.vu.edu.au/apa-referencing/patents-and-standards |
|
Several examples are provided here: http://guides.library.uoit.ca/standards/citing , with references to their sources. |
|
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:
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
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:
|
|
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. |
|
I've been asking for this feature on the Zotero forum since 2006 as well. I like @ewa format idea. 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. |
|
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? |
|
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. |
|
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. |
|
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. |
|
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) 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. |
|
hope it finish soon |
|
WRT the definition of a "Standard", and "Type" it can get confusing, especially for American standards since there is no standardisation for American standards (no pun intended). That's because there is no overall ruling national standards body in the USA. ANSI is only advisory and "co-ordinating", unlike the status of national standards bodies elsewhere in the world (for example in Germany it is DIN, in UK it is BSI etc). The USA has a very complex and inconsistent series of associations that issue standards: there's >10,000 of them. Compared to in a given EU Country that has 1 or 2. (1) The ASTM defines a Standard as:" In ASTM terminology, standards include test methods, definitions, recommended practices, classifications and specifications" (ASTM Charter). (2) NACE another American-based standards body (National Association Corrosion Engineers, now combined with AMPP) defines a Standard as: (3) API (American Petroleum Institute) issues the following as "standards": I recommend calling all the above "Standards", and then distinguishing them by the "Type" field. |
|
Perhaps I missed it, but this issue of how to classify a TECHNICAL standard is already quite exhaustively covered by ISO itself: International Classification for Standards (ICS). It's like a Dewey-Decimal system for Standards (in fact its website says exactly that). Wikipedia has a reasonable description of it: And the current database/listing for the ISO standards following it are at: And Document Center has a Search scheme using it, that includes ISO, ASTM, DIN, BSI, IEC ANSI has a search engine using it for American standards: ICS can be applied to ANY technical standard, and it's actively used by: The goal of ANSI (the US federally funded standards body) is to gradually get all American standards bodies under its wing...which might occur before the metric system is adopted...:-} Therefore, Zotero should have a structured input for ICS classification. |
|
In fact, ANSI uses the ICS classification itself to classify the various SDO's (Standards Developing Organisations). Look at the tab for "View by Industrial Sector". Each Category is the ICS one. Unfortunately due to the embyonic nature of standards standardisation in the USA, not all SDO's are ANSI certified, and very few use the ICS classification on their standards. However, for European standards, the link works both ways. |
|
Hi: I raised the issue of Engineering Standards in 2012: And I understood it was on the "To Do" list, and was expected in maybe a year. No blame, but I made suggestions then, and I think that my above input good, and is well supported. I work with standards as both a User, and to help draft them. And I'm aware of the differences between US standards and European/ISO ones. As I see it, with Zotero, adding an Item Type "Standard" is better than what exists now: which is nothing. Generically, ALL Standards follow this route (American, European etc etc): (2) Then some entity works on the Standard, and issues a Draft And we need to document: (3) Issued Standard: And you often have multiple Organisations that use pretty well the SAME Standard Body But it will ALWAYS have an associated "Parent" Organisation that did the initial creation of it. In Europe ( by which I mean the EEC: Europe Economic Community, not just the EU) many standards have 2 if not 3 Organisations linked to them: In the USA, you could have two organisations linked to a given Standard: However, it is not so often (I suspect never: I've not seen it to my recollection) that a "homegrown" standard by most American SDO's would be adopted as-is by ISO, An example is BS EN ISO/ASTM 52915:2017 Specification for additive manufacturing... And if you look at the related ASTM listing of it (ASTM ISO/ASTM 52915) the body is SIMILAR but NOT identical to the ISO/ASTM 52915 standard. THEREFORE, my point is, Zotero needs to distinguish the RELATED Organisations with a given standard (and indeed, which one is the PARENT, or perhaps RULING organisation. This is more critical with Standard with an American link. In Europe, the CEN format is often taken in as-is for an ISO Standard. And the EXACT same Standard is issued by ALL the National Bodies of the EEC (31 in total, from Austria thru to UK), but only differing in the first part of the title of the Standard (the National Standards body will have its own initials there), and usually a cover page (and often a translation into the country's own language). My point is that it's important to identify the "parent" organisation for Standards, as well as the other Organisations that has re-issued it, if that is the case. Perhaps this all sounds confusing, but if Zotero intends to have some sort of robust consistent classification for Standards, then this is important to understand. |
You do realize when you posted this, yes? There is indeed a bit too much going on, but for what I gather are the main new issues:
|
|
There are examples with authors in this thread. IETF RFCs have authors. I assume for a committee you'd just use the single-field mode. |
|
OK, thanks for feedback. (1) Author/Creator field: Perhaps the best would be to have the "Author" field read "Creator". Then for Standards, one would enter the Committee that wrote it. (2) Status: (3) Publisher: (4) Multiple Bodies: One prime case of being useful is for the bulk of American standards. A Zotero user might not decide to enter anything for any other Body, but the option should be there. Perhaps this is not obvious to people with a non-technical foundation, but standards by their nature are....standardised. |
I would argue that by their very nature, that Standards do not have an "Author". A mainstream standard (from ISO, EN, ASTM, IEC etc) has a COMMITTEE comprised of technical matter experts who contribute their expertise, and there is often a 2nd group of professionals from the supporting Standards (parent) Organisation who take that and actually draft (write) the Standard. Are either of these an "Author" in the same sense as they are for other references? I would argue that compared to other references that Zotero covers, that "Author" for a Standard is split into two parts: Is closer to someone who hires a ghost writer to write something. |
|
Sorry, but this is just not a helpful way to engage. Your expertise is welcome, but only if you can contribute it with an open mind and some humility & respect to the expertise and interest of others. Otherwise, I'd suggest writing your own app. |
|
I think there are a lot of perspectives being presented here which may lead to misunderstandings (I love this 🥳), examples being:
I would add some snippets to these aspects:
But finally I have to say as an end user I am very happy to use Zotero, and look forward at what the development team will do towards standards. We can contribute input from various points of views here (and this may be quite inconsistent and contain contradictions), but it's up to the real developers to blend this in a fully specified, impeccable CSL schema that will work with Zotero and all CSL using apps out there 🤩. |
|
Here are some examples of citations to standards (in APA Style, 7th Ed.): https://apastyle.apa.org/style-grammar-guidelines/references/examples/iso-standard-references I don't see anything super specific or incompatible in the usage of authors field. FGN |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
dstillman is Zotero's lead developer. I co-maintain the Citation Style Language, which is responsible for the automated citations produced by Zotero, i.e. directly relevant code for this issue. In fact, the majority of the people posting here have directly contributed to Zotero and/or CSL. humility is relevant because you can't contribute effectively to a collaborative project if you're not willing to listen to and appreciate what other contributors have to say and that you might on occasion be wrong -- see e.g. your dismissal of Internet standards, Chinese requirements for citing standards, as well as the expertise of developers in how to implement specific metadata and citation requirements in software they've been working on for over 15 years. |
|
OK, here's what we have:
(And Abstract will likely move in a future redesign, putting Organization immediately below Author.) |
|
Looks good to me. The open questions I have from looking again at ISO metadata as well as the discussion & additional detail provided above. For context here's what ISO seems to consider the key metadata for their standards (in addition to number & title) Based on this:
I think that's it -- I'm pretty sure this covers all citation examples we have above and a good bit more for eventualities & future developments (and, as for all complex types, obviously doesn't capture the full complexity of available Metadata). |
|
OK, thanks. I'm fine adding |
Yes, exactly |
|
Would you be able to show an example on e.g. I have my doubts about how universal it really is, and some of the fields are not really clear to me. Thank you. |
|
Title: Quality requirements for fusion welding of metallic materials - Comprehensive quality requirements And optionally The others follow the same logic |
So nothing like dividing "Part 2", subpart name, preliminary code (ENV), catalogue / national number (73 1201),... ? |
|
Correct. There's no way we're going to disassemble the standard numbers. I understand the individual parts have meaning, but I don't think it makes any sense to store them as individual fields in the context of an app like Zotero. |
|
Does anybody working on a standard template right now? |
|
There's no work left afaict. It'll land with the next batch of new item types/fields |
|
Is that planned for a specific time, or just when everything is ready? |
|
@dstillman may we ask to release these changes? |
and others
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:
well, it could also make sense to include all these four into one field. This might make it much easier!?
maybe:
i hope i didn't miss a lot, so feel free to comment and make more suggestions :-)
The text was updated successfully, but these errors were encountered: