The new `docid` situation needs explanation

[strogonoff]

https://github.com/ietf-ribose/relaton-data-ids/blob/ada21210b34d3095bcb9399cd56dc3a6edb535e4/data/draft-donley-behave-deterministic-cgn-02.yaml#L14-L21

[strogonoff]

1. What are the exact semantics of type here? “Internet-Draft” and “IETF” are clearly different taxonomy axes.
2. What are the exact semantics of id? Why do some IDs start with I-D and others don’t?
3. What is the meaning of scope=anchor here, again?

[strogonoff]

BibXML service considers multiple bibliographic items that contain the same document ID (a pair of id and type) to represent a single document. This is following the presumed semantics of what a document ID is.

If draft-donley-behave-deterministic-cgn-02 and draft-donley-behave-deterministic-cgn-03 are not the exact same document, then these bibliographic items should not share the same ID I-D donley-behave-deterministic-cgn.

• If they are different related documents (one being a new version of the other), why not use Relaton relations?
• If there is a case for citing an unversioned ID draft-donley-behave-deterministic-cgn[0], we could generate the relevant bibliographic item and it could contain relations to other versions.

[0] This case is still dubious to me. If author doesn’t care which version of a document to cite, how could this be even called “citing”? Presumably the contents can change! IMO it would be better if author tooling enforced that the exact version is cited, and resolved unversioned reference to the latest version available at the time of citing for author’s convenience.

@ronaldtse

[ronaldtse]

@strogonoff it was explained in some other ticket already that an Internet-Draft has a versioned reference and an unversioned reverence. The unversioned reference always points to the newest versioned reference.

And yes, this is of course citing, which you can see in ISO 690.

If there is a case for citing an unversioned ID draft-donley-behave-deterministic-cgn[0], we could generate the relevant bibliographic item and it could contain relations to other versions.

Let me clarify here. No, expanding an unversioned reference into versioned references will not be sufficient and is in fact incorrect.

Because at cite time, we do not know what the latest version is. The unversioned citation is “always pointing at the newest version” and when a users cites like this, it is an explicit choice. This is very very common in standards publications. The unversioned reference can only be resolved “at read time”, not at “cite time” or during authoring.

[ronaldtse]

For reader behavior, I would say that “at read time” the correct thing to do is what you’ve proposed - resolve the unversioned reference and then all its relations to its versions, then the user can see how the reference evolved and therefore know how usage of this standard has been impacted.

[strogonoff]

The unversioned reference can only be resolved “at read time”, not at “cite time” or during authoring.

I don’t think this can be called “citing”. This could be another type of reference, maybe a link or a relation, but to use the word “cite” in its dictionary meaning one has to know exactly what is being cited at authoring time.

(I.e., I cite X in support of my statement Y. At the time, the version is X1, and I can’t know what changes X2 introduces, and whether it will support my statement. If X2 introduces changes, reader can review X2 if they want.)

I think this goes deeper into authoring tool matter and possibly Metanorma’s handling of links/references.

For reader behavior, I would say that “at read time” the correct thing to do is what you’ve proposed - resolve the unversioned reference and then all its relations to its versions, then the user can see how the reference evolved and therefore know how usage of this standard has been impacted.

Yeah, that makes it look more like a link. Presumably this is outside of BibXML service scope and has to do with final document delivery…

[strogonoff]

By the way, your point about resolving things at reading stage—that strikes me as the appropriate way to deal with citations, but not in the way you described.

What should happen: author cites precise version (the one they can actually read before publishing!); at reading time user’s software optionally resolves to a newer version via relations.

[strogonoff]

Anyway, the question about the nature of citing is more abstract and longer term.

The questions raised in my first comment, and beginning of the second are more immediately pressing regarding data consistency in relaton-data-ids as BibXML service source.

[TonyLHansen]

I don’t think this can be called “citing”. This could be another type of reference, maybe a link or a relation, but to use the word “cite” in its dictionary meaning one has to know exactly what is being cited at authoring time.

Citing a series is always acceptable within the dictionary definition. People cite "the OED" or "Merriam Webster" all the time without reference to which edition. But when you look it up, you go to the most recent one that you have access to.

Citing a non-numbered I-D has always been a reference to the series, represented by the most recent one available.

It's not perfect, but it works in practice.

[strogonoff]

I suspect I’m using “citation” to mean something else. To me “citation” and “reference” mean different things—anything could be referenced (a series, a family of documents, a webpage, etc.), but only a specific document version (or an archived version of a webpage at a particular point in time) is fit for citing unambiguously.

I’ll seek more details on use cases for BibXML service and authoring tooling that integrates with it and how citing works.

People cite "the OED" or "Merriam Webster" all the time without reference to which edition

I mean, sure for casual conversational use where one rarely cares about a definition changing between say Webster’s Seventh and Webster’s Eighth :)

From normalization standpoint, we can hardly (or not at all) infer which version used to be current at authoring time, but we can always infer which version is current at reading time. (Author’s tooling could take care of getting the current version and reader’s tooling can also link to the latest version. But I agree that this is more abstract, since I don’t think we have reader tooling that can facilitate this.)

[rjsparks]

@Stroganoff: Is there anything left to do with this issue? If not, please close it? (We missed the first anniversary of it's creation by a couple of days...)