Provide contributor contact instead of “place”

[strogonoff]

This:

https://github.com/ietf-ribose/relaton-data-ids/blob/d30e8cc56a5fc020c16f40b0c0b452ebd2cfdf57/data/draft-3k1n-6tisch-alice0-00.yaml#L115-L116

Should probably reside within contacts here:

https://github.com/ietf-ribose/relaton-data-ids/blob/d30e8cc56a5fc020c16f40b0c0b452ebd2cfdf57/data/draft-3k1n-6tisch-alice0-00.yaml#L26-L32

[rjsparks]

Do not try to put an address on the IETF. Freemont is not right at all. "The Internet" would be closer. But remaining silent is the right thing to do.

[larseggert]

+1 on not having a place.

Could someone explain what a contributor status signifies? I'd agree that he IETF is a publisher of Internet-Drafts, but the plain English definition of contributor has connotations that are unlikely to make sense here.

[rjsparks]

Listing the IETF as a contributor in this block is a new concept. While being the publisher is arguably not wrong, claiming that the publisher is a contributor is a new semantic, and has consequences with the IETFs definition of contributor.

I think this block should be removed from the contributor: block altogether.

[strogonoff]

Could someone explain what a contributor status signifies? I'd agree that he IETF is a publisher of Internet-Drafts, but the plain English definition of contributor has connotations that are unlikely to make sense here.

Some background: the service uses Relaton as internal bibliographic item format. The format was designed to accommodate documents by any SDO, as a result of which semantics across SDOs may clash.

In this case, I believe Relaton’s data model uses the “contributor” property to describe every entity that participated in the creation of the document, including editors, translators, authors and publishers. The role of the contributor is reflected via the “role” property. Presumably, spec designers believed that “contributor” is a generic enough term, but it turns out it clashes with “contributor” as used by IETF.

I believe Relaton spec could be reviewed regarding either the naming of the “contributor” property, or whether it should contain publishers (cc @ronaldtse?).

However, since the format is ultimately internal, I’d put forward that issues like these could be dealt with at the display layer of IETF BibXML service rather than the data source. That is to say, if the term “contributor” should not appear in the GUI in such context, this can be accommodated. Web GUI was initially built to pass through Relaton property names for simplicity, but it was not an explicit design decision and can (should?) be changed with little effort.

(Sorry for duplicate comment, I didn’t expect GitHub to interpret Cmd+Enter as submit shortcut.)

[rjsparks]

Even having the notion appear in a publicly accessible intermediate format this way is going to be problematic.

[strogonoff]

Fair enough. @ronaldtse @opoudjis it looks like the use of Relaton for this project may not be possible unless the contributor field is renamed due to vocabulary clash, could we use a more explicit and precise term? For example, participant, involved_party, involved_entity or something like that. I’m not sure which repository this issue should be filed in, perhaps https://github.com/relaton/relaton-models/?

Edit: or alternatively could we make all ietf-ribose/relaton-data-* repositories private?

[strogonoff]

For the record, here’s the list of possible roles a contributor (per Relaton’s concept) can have so far:

"author" | "performer" | "publisher" | "editor" | "adapter" | "translator" | "distributor"

[rjsparks]

Trying to follow the above suggestion. Just renaming the container isn't going to address the whole issue. This idea of throwing the IETF into a container with the authors with a formal role of "publisher" is, I think, going to be problematic regardless of the container name.

And while you're thinking about this in addition to "contributor" meaning something special from the IETF's IPR rules point of view, there is a not-tightly-defined concept of a "contributor's" section being used in many drafts and RFCs at this point and it is not an appropriate time to put this in the same bucket with authors in the references.

[rjsparks]

For the record, here’s the list of possible roles a contributor (per Relaton’s concept) can have so far:

does can imply must?

[strogonoff]

And while you're thinking about this in addition to "contributor" meaning something special from the IETF's IPR rules point of view, there is a not-tightly-defined concept of a "contributor's" section being used in many drafts and RFCs at this point and it is not an appropriate time to put this in the same bucket with authors in the references.

I see. That was my initial interpretation, I stand corrected and since I’m removed from relevant context I’ll abstain from any further suggestions and leave it to spec development team to sort out.

does can imply must?

I think those are just available values of contributor[*].role in Relaton data model.

[ronaldtse]

@rjsparks we can definitely omit the Publisher "place". Just to clarify that there are typically two "places" allowed in a reference:

• Place of the publisher. This is from traditional citation practice (and used in ISO 690)
• Place of individual contributors. This is the per-contributor address. A publisher "could" be a contributor, but it may not be.

So we will remove mention of the Publisher "place" (which is of course optional).

[ronaldtse]

For the record, the semantics of "contributor" mirror the ISO 690 data element "Creator", of which the partial description is provided below:

The semantics of "Place" is described in ISO 690 "Production information".

[strogonoff]

I think after @andrew2net’s change this can be closed.