Struktur des pb@facs-Attributs dokumentieren

[funkyfuture]

die struktur der zeichenkette, die auf ein Faksimile deutet, sollte dokumentiert sein, um die interoperabilität sicherzustellen. nme sollte auch das verwenden von urls zulässig sein.

[susannehaaf]

Dokumentation: Stimmt, wird ergänzt. Schematron-Constraints dazu gibt es übrigens schon (id="facsInsideFirstPagebreak", id="facsInsidePagebreaks", id="facsOutsidePagebreaks"). URLs: Den Vorschlag werden wir erwägen.

[xlhrld]

Ja, bitte unbedingt den URI-Vorschlag wohlwollend prüfen. In vanilla TEI ist das schließlich auch

1–∞ occurrences of teidata.pointer separated by whitespace

also eine Liste von URIs. Das jetztige Format #f[Bildnummer] entspricht ja formal einem Fragment-Identifier, was es meiner Meinung nach zusätzlich verwirrend macht; die Faksimiles sind ja in der Regel nicht Teil der Transkriptdatei. Auf Faksimiles unabhängig vom Hostingsystem verweisen zu können, finde ich wichtig.

[funkyfuture]

unbedingt möchte ich das verwenden von URLs auch in den dokumenten des DTA empfehlen. eine demoanwendung eines frameworks, das ich implementiere, scheitert gerade bei der faksimiledarstellung daran, dass aus den xml-dokumenten des DTA die URLs zu den einzelnen faksimile nicht ableitbar ist.

[haoess]

Ganz unmöglich ist es nicht:

<xsl:template match='tei:pb'>
  <xsl:element name="img">
    <xsl:attribute name="src">
      <xsl:text>https://media.dwds.de/dta/images/</xsl:text>
      <xsl:value-of select="//tei:idno[@type='DTADirName']"/>
      <xsl:text>/</xsl:text>
      <xsl:value-of select="//tei:idno[@type='DTADirName']"/>
      <xsl:text>_</xsl:text>
      <xsl:value-of select="substring-after(@facs,'#f')"/>
      <xsl:text>_160px.jpg</xsl:text>
    </xsl:attribute>
  </xsl:element>
  ...
</xsl:template>

Anstelle von 160px sind auch folgende Werte möglich:

• 250px
• 400px
• 800px
• 1600px

[funkyfuture]

nun, dies setzt aber folgendes voraus:

• die url-basis sei statisch für alle dokumente, sowohl hinsichtlich der beinhalteten host- und pfad-namen und der struktur (_ als separatoren)
  • folglich kann ein tei-/dtabf-viewer nicht generisch für dokumente mit referenzen auf faksimile aus verschiedenen quellen implementiert werden
• die url der faksimile beinhaltet den dokumentnamen wie er im dta-repositorium bereit gestellt wird; das ist nicht portabel, etwa wenn die dokumente an anderer stelle nach einem inhaltshash, einer uuid oder noch 'sprechender' als dateinamen abgelegt sind
• analog müssen die verfügbaren auflösungen zur bildung der url bekannt sein, und es ist eben nicht anzunehmen, dass andere repositorien dies identisch wie das dta tun

bzgl. der bildgrößen scheint ja I³F der relevante state-of-the-art zu werden, aber gut, das ist ein anderes fass.

[susannehaaf]

Könnte alternativ die <refsDecl> im <teiHeader> hier Abhilfe schaffen (refsDecl)? Zumindest könnte die URI somit aus demselben TEI-Dokument erschlossen werden. Und es wäre die weitaus schlankere Tagging-Variante.

[funkyfuture]

Könnte alternativ die im hier Abhilfe schaffen (refsDecl)?

perfekt.

[xlhrld]

Hm, mit canonical references sind Legacy-Referenzsysteme gemeint, die übliche und tradierte Zitierweisen in bestimmten Communities repräsentieren. Sowas wie Lukas 2,25 zur Adressierung von Bibelstellten. Mit refsDecl Kann man beschreiben, wie diese Zitierform strukturiert ist (und gegebenenfalls Abbildungen auf ein anderes Referenzierungssystem angeben).

Das Problem bei der Strukturierung des Inhalts von @facs ist ja gerade, dass es bereits einem existierenden Referenzsystem entspricht, das man so irgendwie »umbiegen« würde. Das sollten wir nicht tun.

[textloop]

Zur Nutzung von refsDecl:

Das zweite Anwendungsbeispiel auf http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-refsDecl.html zeigt, dass auch die TEI-Guidelines das Element nicht nur für "canonical references" im strengen Sinne benutzen, sondern auch Umschreibungen in Prosa zulassen. Aus meiner Sicht wäre es vertretbar, wie von @susannehaaf vorgeschlagen.