Open wkumari opened 2 years ago
@wkumari Thank you for raising this issue. You are not seeing the organization affiliations for RFCs because the authoritative data source, the RFC Editor, does not make that information available for indexing.
In particular, the original data source only contains names of authors/editors:
<rfc-entry>
<doc-id>RFC8244</doc-id>
<title>Special-Use Domain Names Problem Statement</title>
<author>
<name>T. Lemon</name>
</author>
<author>
<name>R. Droms</name>
</author>
<author>
<name>W. Kumari</name>
</author>
<date>
<month>October</month>
<year>2017</year>
</date>
<format>
<file-format>ASCII</file-format>
<file-format>HTML</file-format>
</format>
<page-count>25</page-count>
<keywords>
<kw>SUN</kw>
<kw>SUTLD</kw>
<kw>RFC6761</kw>
</keywords>
<abstract><p>The policy defined in RFC 6761 for IANA registrations in the "Special-Use Domain Names" registry has been shown, through experience, to present challenges that were not anticipated when RFC 6761 was written. This memo presents a list, intended to be comprehensive, of the problems that have since been identified. In addition, it reviews the history of domain names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names.</p><p> This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of Special-Use Domain Names.</p></abstract>
<draft>draft-ietf-dnsop-sutld-ps-08</draft>
<current-status>INFORMATIONAL</current-status>
<publication-status>INFORMATIONAL</publication-status>
<stream>IETF</stream>
<area>ops</area>
<wg_acronym>dnsop</wg_acronym>
<doi>10.17487/RFC8244</doi>
</rfc-entry>
Perhaps you could petition the RPC and the RFC Editor to provide this information in the data source. If that happens, the BibXML service would be able to execute your query as desired.
Ping @rjsparks @kesara @ajeanmahoney @lbartholomew-rpc
This is not a priority for the immediate work on the bibxml service, but a reaonable feature request for future evolution.
Thanks @rjsparks for the clarification!
@rjsparks it might be useful to mark this issue with a label of "feature request" and update the title to keep in mind (I don't have edit access here).
Describe the issue
The RFC schema contains a organization field, and the API documentation implies that this can be used: https://bib.ietf.org/api/v1/#operation/searchBibItems (contributor -> person -> affiliation)
From this I'd assume that something like: '{"contributor": [{"person": {"affiliation": {"name": ["Google"] }}}]}' should work, but it returns: "No bibliographic items were found matching the query."
It appears that the organization, affiliation, etc fields are basically always empty, even though it is populated in documents -- e.g from RFC 8244.json: {"role": ["author"], "person":{"name": {"completename": {"content": "W. Kumari", "format": null, "script": ["Latn"], "language": ["en"]}, "prefix": null, "forename": null, "initial": [{"content": "W.", "format": null, "script": ["Latn"], "language": ["en"]}], "surname": {"content": "Kumari", "format": null, "script":["Latn"], "language": ["en"]}, "addition": null}, "affiliation": null, "contact": null}, "organization": null}]
But the document itself has this populated, and tools like the 'draft_metadata_extractor.py' worked just fine with it: docaffiliations='Ted Lemon ted.lemon@nominum.com (Nominum, Inc.), Ralph Droms rdroms.ietf@gmail.com (), Warren Kumari warren@kumari.net (Google)'
It seems like either the datastore / files should be updated with the info, or the API documentation should make it clearer that many of the selectors are not populated.
Code of Conduct