Rendering personography

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Rendering personography

Chris Selwyn
I have been struggling with how to handle my personography.

I understand from the TEI Guidelines Ch. 13 how to construct a
personography by making a separate file which contains a <listPerson> of
<person> elements. I can also see from Ch. 13 how to refer to those
entries using an @ref.

What I am failing to see is how the TEI XSLT stylesheets render the @ref
attributes into a clickable links in HTML.

Is there something obvious I am missing or is the rendering supposed to
be left up to the developer to decide how to do it? Does anyone have a
worked example?

Chris Selwyn
Reply | Threaded
Open this post in threaded view
|

Re: Rendering personography

Elisa Beshero-Bondar-2
Dear Chris,
As you’re finding, personographies are hard work—and I sometimes think of the lists of names and ids as something like  the “backbone” of many a TEI project—something that can be used to connect and integrate all the project pieces based on commonly referenced names. You can construct lists of places (listPlace), lists of organizations (listOrg), lists of texts (listBibl), lists of events (listEvent), etc., and yes, of course we want to use these as the basis for generating clickable links in a web interface of our projects. This part takes a lot of planning, but you might think of the TEI personography (or prosopography listing) as a foundation or framework on the strength of which the website is built.

For link-ability, the attribute you really need in your personography is the xml:id, because with that you’re applying a unique identifier to each name on your list. When you reference a name on a page somewhere in your site, and you generate a link to reveal more information, you’ll be linking to something that holds that unique identifier. There are lots of ways to do this: You can use @ref attributes on something like 
<name ref=“#id”>Jaime</name> inside a given document’s running text, with the understanding that the @ref attribute points to a <person> element in your personography:

<person xml:id=“id”><persName><surname>Lannister</surname><forename>Jaime</forename></persName> 
</person>

The trouble (as you’ve noticed) is that the @ref isn’t a complete link. (Indeed(!) I’ve heard experts on Linked Open Data comment that this simple referencing of an identifier is not good practice, and really those @ref values ought always to be full URLs).  Well, you can and should, in writing or adapting XSLT, add the foundation of a URL to those values, and of course that means you need to store your personography in some form (XML or HTML) at a URL you can reach. Much depends on where you are storing your project files and how they interact with one another. You can build a network of files on an Apache web server yourself or work with a service like the TAPAS project (http://www.tapasproject.org/) which might be a good way to get started with integrating a personography file with a project as you’re learning your way. 

 I recommend working with eXist-db (an XML database) if you have lots of XML files that you want to be connected to your personography file. There are some great tools and plugins in eXist (such as TEI Publisher) to help facilitate HTML transformations and the generation of links, although others with more experience could probably report on how this handles personography files. I also recommend checking out CETEIcean (https://github.com/TEIC/CETEIcean ), which I admire because it preserves the semantic richness of the TEI in HTML 5. All of this takes some adaptation, and I guess I’m laying out the proverbial garden of forking paths here: There are many possibilities, and yes, this is up to the developer to decide how to proceed in building on the XML code.

Here’s a small example from one of my projects: http://digitalmitford.org/getLetterText.php?uri=1823-03-25_Haydon.xml . On mouseover of an underlined name, you’ll see blue pop-up notes: Those are pulled in from my personography file.
The file itself is here: http://digitalmitford.org/si.xml

Here’s what’s happening to link the files: I store my “ography” XML file on my project web server and point my rendered letters pages at that file when I need to “pull in” material for annotations—basically with an XSLT file that reaches into the prosopography file and steps with XPath into the appropriate person holding an @xml:id. There’s a transformation from XML into HTML that’s happening within a server installation of eXist-db to render the letter in the web browser with its mouseover annotations.

Fair warning: my project files are under development and constitutionally messy—but over time, this will look better as we work on the interface and the content—that’s one of the “organic” pleasures of building on the web. I hope this helps give you some ideas.

Cheers,
Elisa

-- 
Elisa Beshero-Bondar, PhD
TEI Technical Council Member
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail:[hidden email]
Development site: http://newtfire.org






On Dec 9, 2017, at 7:49 PM, Chris Selwyn <[hidden email]> wrote:

I have been struggling with how to handle my personography.

I understand from the TEI Guidelines Ch. 13 how to construct a personography by making a separate file which contains a <listPerson> of <person> elements. I can also see from Ch. 13 how to refer to those entries using an @ref.

What I am failing to see is how the TEI XSLT stylesheets render the @ref attributes into a clickable links in HTML.

Is there something obvious I am missing or is the rendering supposed to be left up to the developer to decide how to do it? Does anyone have a worked example?

Chris Selwyn

Reply | Threaded
Open this post in threaded view
|

Re: Rendering personography

Elisa Beshero-Bondar

PS: Here’s a great example of displaying an “ography” via the TAPAS project:  http://www.tapasproject.org/tapas-commons/files/handling-ography-data-tapas-reader 


Best,

Elisa


On Sat, Dec 9, 2017 at 8:50 PM, Elisa Beshero-Bondar <[hidden email]> wrote:
Dear Chris,
As you’re finding, personographies are hard work—and I sometimes think of the lists of names and ids as something like  the “backbone” of many a TEI project—something that can be used to connect and integrate all the project pieces based on commonly referenced names. You can construct lists of places (listPlace), lists of organizations (listOrg), lists of texts (listBibl), lists of events (listEvent), etc., and yes, of course we want to use these as the basis for generating clickable links in a web interface of our projects. This part takes a lot of planning, but you might think of the TEI personography (or prosopography listing) as a foundation or framework on the strength of which the website is built.

For link-ability, the attribute you really need in your personography is the xml:id, because with that you’re applying a unique identifier to each name on your list. When you reference a name on a page somewhere in your site, and you generate a link to reveal more information, you’ll be linking to something that holds that unique identifier. There are lots of ways to do this: You can use @ref attributes on something like 
<name ref=“#id”>Jaime</name> inside a given document’s running text, with the understanding that the @ref attribute points to a <person> element in your personography:

<person xml:id=“id”><persName><surname>Lannister</surname><forename>Jaime</forename></persName> 
</person>

The trouble (as you’ve noticed) is that the @ref isn’t a complete link. (Indeed(!) I’ve heard experts on Linked Open Data comment that this simple referencing of an identifier is not good practice, and really those @ref values ought always to be full URLs).  Well, you can and should, in writing or adapting XSLT, add the foundation of a URL to those values, and of course that means you need to store your personography in some form (XML or HTML) at a URL you can reach. Much depends on where you are storing your project files and how they interact with one another. You can build a network of files on an Apache web server yourself or work with a service like the TAPAS project (http://www.tapasproject.org/) which might be a good way to get started with integrating a personography file with a project as you’re learning your way. 

 I recommend working with eXist-db (an XML database) if you have lots of XML files that you want to be connected to your personography file. There are some great tools and plugins in eXist (such as TEI Publisher) to help facilitate HTML transformations and the generation of links, although others with more experience could probably report on how this handles personography files. I also recommend checking out CETEIcean (https://github.com/TEIC/CETEIcean ), which I admire because it preserves the semantic richness of the TEI in HTML 5. All of this takes some adaptation, and I guess I’m laying out the proverbial garden of forking paths here: There are many possibilities, and yes, this is up to the developer to decide how to proceed in building on the XML code.

Here’s a small example from one of my projects: http://digitalmitford.org/getLetterText.php?uri=1823-03-25_Haydon.xml . On mouseover of an underlined name, you’ll see blue pop-up notes: Those are pulled in from my personography file.
The file itself is here: http://digitalmitford.org/si.xml

Here’s what’s happening to link the files: I store my “ography” XML file on my project web server and point my rendered letters pages at that file when I need to “pull in” material for annotations—basically with an XSLT file that reaches into the prosopography file and steps with XPath into the appropriate person holding an @xml:id. There’s a transformation from XML into HTML that’s happening within a server installation of eXist-db to render the letter in the web browser with its mouseover annotations.

Fair warning: my project files are under development and constitutionally messy—but over time, this will look better as we work on the interface and the content—that’s one of the “organic” pleasures of building on the web. I hope this helps give you some ideas.

Cheers,
Elisa

-- 
Elisa Beshero-Bondar, PhD
TEI Technical Council Member
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail:[hidden email]
Development site: http://newtfire.org






On Dec 9, 2017, at 7:49 PM, Chris Selwyn <[hidden email]> wrote:

I have been struggling with how to handle my personography.

I understand from the TEI Guidelines Ch. 13 how to construct a personography by making a separate file which contains a <listPerson> of <person> elements. I can also see from Ch. 13 how to refer to those entries using an @ref.

What I am failing to see is how the TEI XSLT stylesheets render the @ref attributes into a clickable links in HTML.

Is there something obvious I am missing or is the rendering supposed to be left up to the developer to decide how to do it? Does anyone have a worked example?

Chris Selwyn


Reply | Threaded
Open this post in threaded view
|

Re: Rendering personography

Thomas Stäcker
In reply to this post by Elisa Beshero-Bondar-2
Dear Elisa,

just a brief remark on the line below. As long as the identifier is referenced by a fragment ID, i.e. with #, it is in a way a full URL according to https://tools.ietf.org/html/rfc3986, because the remainder of the link is to be supplemented by the base URL. If this is convient is another matter. Accordingly, the difference between a so called "full" URL and a fragment or abbreviated URL would only be that the information about the entity can be found either in the same or in another document.

Best,
Thomas




Am 10.12.2017 um 02:50 schrieb Elisa Beshero-Bondar:
experts on Linked Open Data comment that this simple referencing of an identifier is not good practice, and really those @ref values ought always to be full URLs)

-- 
***************************************
Prof. Dr. Thomas Stäcker
Direktor der
Universitäts- und Landesbibliothek Darmstadt
Magdalenenstr. 8
64289 Darmstadt
+49 (0)6151 16-76200
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Rendering personography

Peter Stadler
In reply to this post by Chris Selwyn
Hi Chris,

tl;dr: yes: the rendering is left up to the developer.

you’re right, the TEI Stylesheets transformation to HTML does not process any @ref or @key on <persName> (to be turned into clickable links). One issue I see is that the referenced <person> elements do not get processed when they are in the header (where you frequently put these). So, there is frequently nothing to point to in the HTML …
Second, those links might nest: <persName> can self-nest or be within a <ref> or within a <placeName> or …
So, as I learned from my projects, you can’t simply turn every <persName> into an <html:a> because in HTML these elements must not nest.

That said, I totally agree that your request is not at all fancy but common practice – I just do not see how the TEI Stylesheets could take care of the aforementioned issues in a generic way (and with affordable efforts).

Cheers
Peter


> Am 10.12.2017 um 01:49 schrieb Chris Selwyn <[hidden email]>:
>
> I have been struggling with how to handle my personography.
>
> I understand from the TEI Guidelines Ch. 13 how to construct a personography by making a separate file which contains a <listPerson> of <person> elements. I can also see from Ch. 13 how to refer to those entries using an @ref.
>
> What I am failing to see is how the TEI XSLT stylesheets render the @ref attributes into a clickable links in HTML.
>
> Is there something obvious I am missing or is the rendering supposed to be left up to the developer to decide how to do it? Does anyone have a worked example?
>
> Chris Selwyn
Reply | Threaded
Open this post in threaded view
|

Re: Rendering personography

Elisa Beshero-Bondar-2
In reply to this post by Thomas Stäcker
Dear Thomas,
Yes—that is how I have tended to think of the fragment ref=“#ID”, too, and thank you for the specs reference. What’s clear is that there needs to be information to process the full URL somewhere else in the document and that this should be specified. 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. 

I think, with you, it’s easily resolved by documentation of the rest of that URL! 


Cheers,
Elisa

-- 
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail:[hidden email]
Development site: http://newtfire.org






On Dec 11, 2017, at 2:44 AM, Staecker <[hidden email]> wrote:

Dear Elisa,

just a brief remark on the line below. As long as the identifier is referenced by a fragment ID, i.e. with #, it is in a way a full URL according to https://tools.ietf.org/html/rfc3986, because the remainder of the link is to be supplemented by the base URL. If this is convient is another matter. Accordingly, the difference between a so called "full" URL and a fragment or abbreviated URL would only be that the information about the entity can be found either in the same or in another document.

Best,
Thomas




Am 10.12.2017 um 02:50 schrieb Elisa Beshero-Bondar:
experts on Linked Open Data comment that this simple referencing of an identifier is not good practice, and really those @ref values ought always to be full URLs)

-- 
***************************************
Prof. Dr. Thomas Stäcker
Direktor der
Universitäts- und Landesbibliothek Darmstadt
Magdalenenstr. 8
64289 Darmstadt
<a href="tel:+49%206151%201676200" value="+4961511676200" target="_blank">+49 (0)6151 16-76200
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Rendering personography

richard light

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.
Elisa,

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

--
Richard Light
Reply | Threaded
Open this post in threaded view
|

Re: Rendering personography

Birnbaum, David J
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 http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAPU

Best,

David

From: TEI-L <[hidden email]> on behalf of Richard Light <[hidden email]>
Reply-To: Richard Light <[hidden email]>
Date: Monday, December 11, 2017 at 9:23 AM
To: TEI-L <[hidden email]>
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.
Elisa,

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

--
Richard Light
Reply | Threaded
Open this post in threaded view
|

Re: Rendering personography

Chris Selwyn

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?

Chris


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 http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAPU

Best,

David

From: TEI-L <[hidden email]> on behalf of Richard Light <[hidden email]>
Reply-To: Richard Light <[hidden email]>
Date: Monday, December 11, 2017 at 9:23 AM
To: TEI-L <[hidden email]>
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.
Elisa,

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

--
Richard Light

Reply | Threaded
Open this post in threaded view
|

Re: Rendering personography

Birnbaum, David J

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.

 

Best,

 

David

 

From: Chris Selwyn <[hidden email]>
Date: Monday, December 11, 2017 at 5:49 PM
To: David Birnbaum <[hidden email]>, TEI-L <[hidden email]>
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?

Chris

 

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 http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAPU

 

Best,

 

David

 

From: TEI-L <[hidden email]> on behalf of Richard Light <[hidden email]>
Reply-To: Richard Light <
[hidden email]>
Date: Monday, December 11, 2017 at 9:23 AM
To: TEI-L <
[hidden email]>
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.

Elisa,

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

--
Richard Light



Reply | Threaded
Open this post in threaded view
|

Re: Rendering personography

Birnbaum, David J

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.

 

Best,

 

David

 

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

 

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

Feedback

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.

 

Best,

 

David

 

From: Chris Selwyn <[hidden email]>
Date: Monday, December 11, 2017 at 5:49 PM
To: David Birnbaum <[hidden email]>, TEI-L <[hidden email]>
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?

Chris

 

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 http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAPU

 

Best,

 

David

 

From: TEI-L <[hidden email]> on behalf of Richard Light <[hidden email]>
Reply-To: Richard Light <
[hidden email]>
Date: Monday, December 11, 2017 at 9:23 AM
To: TEI-L <
[hidden email]>
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.

Elisa,

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

--
Richard Light