#310 Encoding RDF relationships in TEI
Hi, I was looking at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-relation.html today, and realized that it comes very close to being able to represent RDF-style triples. Actually, I think it could do so now, but there are a couple of things I'd suggest TEI do:
Example:
<placeName ref="http://sws.geonames.org/361059">Alexandria</placeName>
<placeName ref="http://sws.geonames.org/357994">Egypt</placeName>
...
<relation xmlns:gn="http://www.geonames.org/ontology#" ref="gn:parentFeature" active="http://sws.geonames.org/361059" passive="http://sws.geonames.org/357994"/>
could be a way to encode the triple Alexandria is a child feature of Egypt. My first recommendation would be that the Guidelines say explicitly that using @ref on <relation> enables the encoding of RDF-style triples.
My second recommendation is that the attributes @active and @passive be deprecated and renamed. The names are *extremely* confusing, unintuitive, and fail to describe the attributes' actual function. Better would be @subject and @object (as in "subject, predicate, object"), which is a standard way of describing RDF triples. The relations are directed graphs, so names drawn from graph theory terminology, like @head and @tail would be acceptable also. Likewise @symmetric might be a better name than @mutual, but the latter is less bad than @active and @passive.
It could be argued that @mutual is redundant, but I see the attraction of a single attribute that can express symmetric relationships.
My last recommendation is that the guidelines make it clear that <relation> is not just for persons, but can be used for relationships between places, objects, organizations, etc. I wonder too whether elements like <affiliation> ought not to be considered refinements of <relation>.
There are a couple of free-standing bits to this request, some of which may be easier to decide on than others.
(1) Saying explicitly in the guidelines that @ref may be used with <relation> to reference a relationship-type from an external ontology sounds to me like a no-brainer. If no one objects I propose we accept this now.
(2) Renaming the attributes @active and @passive: I agree in principle, but we really ought to canvess the community (via TEI-L) and see whether anyone is actually using these attributes. If so, we may want to slow down to avoid unnecessarily breaking backward-compatibility.
(2a) Deprecating @mutual: assuming nobody is using this attribute, I'd be in favour of this. But again we need to see who that would hurt.
(3) Extending <relation> for use outside of persons. This question is more tricky, and I think I'd resist just making this a universal linking element from the get-go, at least without much further discussion and research. However, since this element is currently defined for use within a tei:listPerson, I don't think it's a stretch to say we have a pretty good use-case for extending its use to listPlace and listOrg as well. (And maybe listNym?) There's nothing to stop us further extending its use as concrete use-cases arise.
Just a quick note that http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ND.html#place-rel already details how to describe relations between places and people/places, so cat #3 is already out of the bag.
Re: #2a, I'm of two minds about @mutual. It does no harm, and provides a shorthand for cases where relationships are symmetric, so I'm not sure I'd do anything. The name is less objectionable than @active and @passive too.
1) A nitpick or an enquiry concerning `ref="gn:parentFeature"` -- do the Guidelines actually advocate namespaced attribute content anywhere, or is that just a quick way of expressing an idea?
2) I've written here and now erased a critique of @mutual because I've realised that applying <relation> to triples needs to require more than just the usage of @ref -- at present, <relation> in inherently a shortcut, lumping element, with @active and @passive serving to lump together asymmetric and antisymmetric relations, while @mutual serves to lump together symmetric and antisymmetric relations. Triples are cleaner, and what I'm saying is that it will take at least Schematron to make sure we're looking at real triples *when* @ref is used. But then some will say "why resign from encoding multiple triples in a single element" and we're back at the beginning, with triples being "asserted" only in the text of the Guidelines. In yet other words: maybe, just maybe, if this element is to evolve in the direction of the RDF, at least the (renamed?) @active and @passive should allow for single references only.
3) concerning @active and @passive: who is active in "John loves Picasso", or "John loves doing nothing"? A nitpick, of course, but @subject and @object seem indeed better, less assumption-laden -- they don't mix the surfacey issue of the position of an argument in the argument list with the nature of the relationship (experiencing emotions is not really an active role).
4) how about (i) deprecating @active and @passive, and
(ii) using @subject and @object as single-reference attributes, and assert their presence when @ref is used (RDF-like behaviour), and
(iii) using @subjectList and @objectList (to allow for the current, lumping behaviour of @active and @passive), and asserting the respective mutual incompatibility @subjectList and @objectList with @subject and @object?
Ah, thanks to my supreme mental powers I have managed to overlook that @ref holds, as even its name implies, a URI, and have now read up on CURIE, thanks to the TEI-L exchange. So please ignore my #1.
I would love to see RDF-like triples doable in TEI. This is especially important for efforts related to prosopography. I heartily agree with the recommendation concerning @active and @passive.
I would like to see the @subject able to be implicit. (David Sewell deserves the credit for this idea.) E.g., if I have a collection of TEI <person> records then, in the parts that talk about relations (such as child-of, parent-of, sibling-of, friend-of, enemy-of, lived-at, went-to, adjacent-to, formerly-named, located-at, ...), it would be really handy to be able to say "the subject is the immediate ancestor element to which this relation applies" then leave out the implied attribute.
By the way, I think that <trait> is superfluous, an ill-conceived subclass of <state>. Can anyone name an immutable characteristic of a person? I think it would be better to just have states and events. (Each event would then correspond to a state-transition.) Also, I think that the structure of TEI needs to be revised so that prosopography records are more logically structured. I would like to see person records which allow lists of states, relations, events, and places to be included in a simple way. At the moment one needs to do structural gymnastics.
The TEI Ontologies SIG meeting in Wurzburg on 2011-10-14 discussed this ticket
and related issues, and we came up with a number of recommendations,
which I will put in this ticket and subsequent ones.
As regards <relation>, we debated between keeping <relation>, but changing
and adding to its attributes, versus defining a new <relationship> and deprecating
<relation>. In the end, we opted for keeping <relation>, with the following changes:
* change the description from ... "amongst a specified group of participants"
to "...amongst a specified group of objects, places, events or people."
* make it a member of att.canonical, so that it gets @key and @ref
* deprecate @name
* deprecate @mutual
* keep @active and @passive. Although they are confusing, so are @subject and @object,
we believed. For non-English speakers, these are merely tokens anyway, and the usage
is unambiguous.
We suggested adding a new <listRelation> element, and adding that to model.biblLike,
so that we can have free-standing lists of <relation> elements. We suggested that
<relationGrp> be deprecated.
Gabriel's concern that <relation> will become completely generic is unavoidable, we suggest.
For clarity, the new <listRelation> element (which would contain <relation> elements) would be allowed in the same places as the to-be-deprecated <relationGrp> except that it would also be added to model.biblLike so that bibl, biblStruct, and biblFull could contain <relation> elements without needing to wrap these <relation> elements in <relationGrp>.
If you want to use <relation> in order to attach RDF data to bibliographic entities, I think it also makes sense to allow <relation> inside <fileDesc> so that you can attach RDF to a TEI document itself, not just bibliographic citations occurring within <sourceDesc> or somewhere within the <text>.
I'd like to push back on @rahtz's comment a bit re @active/@passive:
"keep @active and @passive. Although they are confusing, so are
@subject and @object,
we believed. For non-English speakers, these are merely tokens
anyway, and the usage
is unambiguous."
In fact these are AWFUL names for a simple pair of concepts. Active/passive are not unambiguous as names for the nodes at either end of a directed arc—they denote concepts that have nothing to do with the role of the nodes. For example, if I say A isCitedBy B, is A active or passive? The "verb" (the arc) is in the passive voice, but you could easily, and wrongly say that B is the actor and A the acted upon. You need to express the concept clearly, whether you use subject/object, or head/tail, or first/second, or something else.
Are you happy with the rest of it, @hcayless? Is the only problem the naming of the attributes? Hopefully the TEI Council meeting next week can discuss this and come to a resolution. I dont think any of us at the meeting in Wurzburg were exactly _happy_ with @active and @passive, but equally we were mindful of making backward-incompatible changes.
Yeah, I think the rest of it makes good sense. I'd suggest deprecating @active and @passive rather than immediately removing them. They'd be replaced by equivalent attributes, so it's not terribly backwards-incompatible.
agreed that we should add @key and @ref to <relation>, change description, leave attribute names for the moment. Ask SIG to raise ticket on the naming issue.
recommendation is to use relationGrp for now since it does the job; add relationGrp to model.biblLike
Changes duly made - add relation to att.canonical, put relationGrp into model.biblLike.
I am not closing ticket yet, as I think an example of relation/@ref should be added to spec.
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
Hi, I've been following this discussion with interest as it is very relevant for us. In the Sharing Ancient Wisdoms project [1] we are marking up manuscripts containing Greek and Arabic collections of wise sayings. We want to use RDF or similar to represent the relationships between and within these collections of sayings.
One thing that is very important for us is to include something like a @resp attribute to mark who is identifying a particular relation. This is because many of our relations are subjective, with different people having different views on how the texts link together.
To achieve this, we have discussed a slightly different format to encode RDF within a TEI document: using the reading element <rdg> with a @rel attribute, within the markup of the subject/active/head itself. E.g.:
Document 1:
...
<seg xml:id="http://www.ancientwisdoms.ac.uk/Th_s3"> [arabic text] </seg>
...
Document 2:
...
xmlns:saws="http://www.ancientwisdoms.ac.uk/ontology#"
...
<seg xml:id="http://www.ancientwisdoms.ac.uk/Th_tr_s3">
<rdg rel="saws:isCloseTranslationOf" resource="http://www.ancientwisdoms.ac.uk/Th_n3" resp="elvira"/>
Whoever performs an action in secret, yet is embarrassed by it in public, is a worthless person.
</seg>
...
(One advantage of this is that multiple readings are possible using this format.)
So my questions are:
1. The suggestion by Hugh Cayless seem to have been more or less agreed? Is there a timescale for when this will be adopted as standard in TEI?
2. Is there a way of incorporating @resp within <relation> ? (or something similar to @resp)
3. Using the format suggested by Hugh Cayless, should our relation example be expressed (with resp...) as:
<relation ref="saws:isCloseTranslationOf" active="http://www.ancientwisdoms.ac.uk/Th_tr_s3" passive="http://www.ancientwisdoms.ac.uk/Th_n3" resp=elvira/>
?
Any comments/feedback welcomed.
[1] http://www.kcl.ac.uk/innovation/groups/cerch/research/projects/current/saws.aspx
@Anna:
1. The changes agreed upon here (pretty much everything suggested by Hugh except for the attribute name changes) should make their way into the TEI guidelines and schema by the end of the calendar year (i.e. in the next few weeks). You should be able to see the current state of <relation/> at http://bits.nsms.ox.ac.uk:8080/jenkins/job/TEIP5-Documentation/lastSuccessfulBuild/artifact/Guidelines-web/en/html/ref-relation.html and see if it corresponds to what you expect.
2. As far as I can see, yes @resp will be available on <relation/> (in fact it already is).
3. That looks reasonable. The value of @resp should of course be a pointer, pointing the the @xml:id of another element describing who is meant by "elvira".
Does this mechanism seem to work well for your purposes, now?
Very useful, thanks Gabriel (and yes you're right, I was a little lazy with the @resp value).
Glad to see these changes will be coming into place so quickly.
I have added an RDF-like example to <relation>, and I hope this closes the ticket for the moment.