<ref> for "in: id., p. 8"

[cboulanger]

Given this bibl:

  <author>
      <persName>
          <forename>N.</forename>
            <surname>Fraser</surname>
        </persName>
    </author>
    and
    <author>
      <persName>
          <forename>L.</forename>
            <surname>Gordon</surname>
        </persName>
    </author>,
    ‘<title level="a">Civil Citizenship against Social Citizenship?</title>’
    <ref type="op-cit">in id.</ref>,
    <citedRange unit="page" from="97" to="97">p. 97</citedRange>.
</bibl>

The annotation <ref type="op-cit">in id.</ref> does not contain enough information for a lookup. There needs to be a hint that what has to be looked for in a previous footnote is the monograph in which the chapter is contained, not work by Fraser and Gordon.

@awagner-mainz

[awagner-mainz]

From what I would say without looking at the article in which this was contained:

The citation style for the piece seems to suggest that after a work has been cited in full (in a footnote probably), subsequent citations can refer to it by only the author's name(s). Probably name plus title are required only if several works by the same author(s) have been cited before. "id."/"idem" means "the same" and usually refers to the same person, whereas "ibid."/"ibidem" would refer to the same place or work. So the reference in this case points to the most recently cited work by Fraser and Gordon. If this is in a (preceding) footnote, we could mention the @xml:id of the footnote in the <ref>'s @target, but even more appropriate would be the @xml:id of the respective <bibl> entry.

Resolving this (manually) obviously has its own difficulties, but is this what the present issue is about, @cboulanger ?

[cboulanger]

id. here refers to the work, not the author - that seems to be a common thing in legal citations - the BlueBook system states that

´"Id." is an all-purpose short form citation that may be used for any cited authority except internal cross-references

If we manually annotate a document, we can of course work with @target and @xml:id attributes. However, since we're looking at ways for automatic resolution of <ref> elements, we need to give the resolution algorithm enough information. In this case, the "in" tells us that the reference is the previously mentioned edited volume, not the previously mentioned work (which is a chapter in this volume) - this is important also because the author and the editor are different.

That's why the <ref> element's @type attribute has to reflect that - otherwise there is no way (except "manual" parsing of the ref's content) for the resolver to know.

[cboulanger]

So maybe something like <ref type="op-cit-analytic"> vs <ref type="op-cit-monogr"> ? We could also use the @subtype attribute but maybe that introduces too much markup complexity.

[awagner-mainz]

Can we tag the in signal word and look up previous works differently based on whether or not such a signal word is present (we'd probably need to introduce a new type of such signals)?

[awagner-mainz]

we could also (additionally, or alternatively) try to retrieve the @level of the corresponding <title> tag to learn whether we are looking for a monograph or analytic bibliographic item...

[cboulanger]

we could also (additionally, or alternatively) try to retrieve the @Level of the corresponding <title> tag to learn whether we are looking for a monograph or analytic bibliographic item..

I am thinking of a situation where the LLM sees only the single unparsed citation string (without any context) and should extract the information which we are trying to find markup for in this issue. So it should infer from the presence of "in" that the missing data is in the most recently referenced monographic item. this is what I want to express for the gold data.

Can we tag the in signal word and look up previous works differently based on whether or not such a signal word is present (we'd probably need to introduce a new type of such signals)?

Wouldn't that be more verbose that simply having a different @type? What do you think the advantage would be?