Dear TEI-L,


With apologies for having to respond to my own posting (that is, for not having finished the thought before hitting the “send” button), I do more with these types of external links than just convert them into in-place links to be rendered. For example, as in the Mitford project that Elisa described earlier, my XSLT sometimes pulls and formats selected information from a personography or other external file and pokes it into the output of converting a different file not as a link, but as rendered textual information. Putting the external base URLs in a standard place, as supported by private URL schemes, enables a developer to construct a full URL in a consistent way, but different developers will want different things for different purposes. If the original question was about the official stylesheets, I wouldn’t ask a generic toolbox stylesheet to be able to anticipate that variety of needs.






From: TEI-L <[log in to unmask]> on behalf of David Birnbaum <[log in to unmask]>
Reply-To: David Birnbaum <[log in to unmask]>
Date: Monday, December 11, 2017 at 6:26 PM
To: TEI-L <[log in to unmask]>
Subject: Re: Rendering personography


This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing


Dear Chris (cc TEI-L),


Yep. I write my own XSLT or XQuery to convert my TEI to my target output, so that’s where I unpack the private URL scheme and construct a link that will work in the output. If the question was about whether the stylesheets distributed by the TEI know how to process private URL schemes and construct working links for all of the supported output formats, I don’t know, and I apologize for the misunderstanding.






From: Chris Selwyn <[log in to unmask]>
Date: Monday, December 11, 2017 at 5:49 PM
To: David Birnbaum <[log in to unmask]>, TEI-L <[log in to unmask]>
Subject: Re: Rendering personography


That seems OK as far as defining the TEI document itself is concerned.

However, wouldn't it be necessary to do further work on that resulting URL depending on what type of processing (EPUB/HTML/PDF/etc.) is being performed in order  to generate a link in that works in the target format?



On 11/12/2017 16:30, Birnbaum, David J wrote:

Dear TEI-L,


To enable an application to dereference a pointer to an external personography file, could one not use what the Guidelines call a “private URL scheme”, as described at






From: TEI-L <[log in to unmask]> on behalf of Richard Light <[log in to unmask]>
Reply-To: Richard Light <
[log in to unmask]>
Date: Monday, December 11, 2017 at 9:23 AM
To: TEI-L <
[log in to unmask]>
Subject: Re: Rendering personography



On 11/12/2017 13:01, Elisa Beshero-Bondar wrote:

In the Linked Data context, the issue seems to be whether our TEI personography files can function in their own right *as* linked (or linkable) data because of they way they express relationships. When the mechanism to put the URL together isn’t readily available in the same document, but left to *undocumented* parsing (as, too frequently in my case, in the XSLT file transforming the TEI document), this poses a problem because the information to create the link is data best stored with the XML document.


If we start from the premise that a TEI document is available on the web at a given URL, it should be straightforward to write an XSLT which generates an RDF expression of all the assertions which it contains, as a single RDF document/graph.  This can include all the people mentioned in the header.  Each person would have a 'hash URI' formed by combining the source document's base URI with their unique ID.  The base URI is available to the XSLT processor, so it is simply a matter of using it effectively.

This approach means that the scope within which the IDs are designed to be unique nicely matches the scope of the generated RDF.  It also means that, with simple URL rewriting rules, you can have document URLs which 'play nicely' with regard to the Linked Data paradigm: delivering XML by default, but returning RDF instead when the Accept header of the HTTP request asks for this response.

One downside of this approach is that you have to download the whole document-sized graph whenever you want to dereference any of the hash URIs within it.  However, there are plenty of precedents for using this strategy, e.g. when declaring a complete ontology as a single RDF resource, with hash URIs for each concept within it.

Best wishes,


Richard Light