RDF is becoming more and more important as a means to represent information that overlaps with TEI's domain, and it is likely that the representation of RDF-style relations in TEI will become correspondingly more important. RDF data is a directed graph of relations, where each triple represents one arc between two nodes (or between one node and some data).
The set of attributes for denoting the ends of the relation arc are @active, @mutual, and @passive. Because the relation element represents one or more arcs in a directed graph, I suggest TEI use the same attributes it uses to indicate the ends of an arc in its own vocabulary for representing graphs: @from and @to. These attributes have the advantage of being unambiguous, unlike the present ones, where it is easily possible for an encoder to become confused about which attribute to use for which end of the arc. This would also normalize the behavior of relation and arc, which are doing essentially the same thing in different domains.
My suggestion would be to add @to and @from to relation and to deprecate @active (@from) and @passive (@to).
Anything reasonable is better than @active and @passive, and if @from and @to have synergy with graph descriptions... My only concern is "directed" the words "the relation element represents one or more arcs in a directed graph". I'm not sure about this restriction, but then, I can imagine ways around it that would make it possible to live with the inherent directionality of "from" and "to".
I think if we wanted directed vs. undirected relations, they'd need to be
expressed using different attributes. Possibly @mutual could be said to
express an undirected link rather than a set of symmetric directed links...
On Mon, Apr 21, 2014 at 5:11 PM, Piotr Banski bansp@users.sf.net wrote:
Related
Feature Requests:
#504Assigning to Hugh Cayless to remind council of this ticket and gather consensus for changes.
I agree 100% with the principle behind this ticket.
@active
and@passive
are not only clunky and misleading, but actively wrong. Neither the referent nor the target of a relation are "active" or "passive" in any of the senses of those words. Whenever I try to present this mechanism to students of TEI or EpiDoc, the confusion caused by the attribute names is effectively a deal-breaker for them. Some give up altogether. Others I am able to persuade to close their eyes and pretend something more intelligent is in there. As Piotr says, almost anything would be better than this.A grammatical metaphor such as
@subject/@object
would be clearer; a graph notation such as@from/@to
would work fine (but see below); logical terms such as referent and referee would be clunky, but at least less wrong than active/passive. I could imagine@target
making some sense, but a mirror element from that would be needed (@match
?).However, sadly the
<relation>
element already takes@from
and@to
from att.dating, and would mean, "This relationship applied between date-x and date-y", so some other suggestion needs to be found. Maybe@relationFrom
and@relationTo
, or similar?+1 for Gabby's point of view: the current names are no good, but @from and @to would cause terrible confusion with dating attributes. @subject/@object seems just a little bit too specific to a few domains to me. @relationFrom and @relationTo are good, but perhaps a bit too long. @towards and @awayFrom? Or just @relTo and @relFrom, with the context making it obvious that rel=relation?
As the onlie begetter of the <relation> element I must protest. These attribute names make perfectly good sense in the context for which the element was intended : modelling relationships amongst people. If we want a way of modelling abstract relationships as in RDF maybe <arc> and friends would be a much better choice, since they come free of semantic baggage. (By the way, the word "relation" is also not unproblematic, if you come at it from a relational database perspective)
we went over this a few years ago, and didn't go down the line of changing attribute names because of the backward incompatibility. Can we justify a break of that magnitude?
i agree that @from and @to are too polluted. @subject and @object are available, surely?
If you read my comment above, you'll see that I am not proposing to change attribute names, but making the rather more radical suggestion that we chose the wrong element to represent the things that are called relations in RDF. If, as Hugh suggests, the main object is to represent RDF in TEI, the element to use is <tei:arc>. Yes, I should have pointed this out before. But I am pointing it out now!
previous discussion at https://sourceforge.net/p/tei/feature-requests/310/, if anyone likes re-reading history :-}
Lou's suggestion of using
<arc>
has merit. But it would need a lot of work toredo all that stuff, and I can't help feeling that exposing the nets module to the light of day is a bad idea. Let it continue to sleep the long sleep of the unused.
It might be unused because it's not as useful as it could be. If
<arc>
is the way to do this (Hugh, could you use it as suggested?) then rewriting a part of the Guidelines to show how seems a relatively painless procedure, with no compatibility implications.I think you'll find that it is used : certainly users leapt out of the wood work when we proposed to abolish it some time back. If my proposal has merit, let's not pervert an existing (also meritorious) element simply out of laziness.
<arc>
's @from and @to can hold only one pointer, but<relation>
's @active and @passive can hold multiple pointers. If the objective is to represent RDF triples, then<graph>
and<arc>
are precisely what is required; if the objective is to model complex relationships among humans, then<relation>
looks to me to be more powerful. It would be trivial to transform<relation>
-based structures into a graph, though.Gabby is right about the att.datable problem. Not sure how I missed that,
but anyway. Relation is currently (and maybe now primarily) used to encode
RDF-style relationships, and that makes the attribute naming a real
problem. The fact that multiple pointers can be used just means a single
relation can encode multiple triples, and I don't think that itself is a
problem.
The real problem is one of sense and usability: the attributes we have
don't have names that express what it is they do, and as Gabby says,
they're confusing enough that people refuse to use them. I will confess I
am one of those people :-). We need a way to be able to say that a relation
has a direction (e.g. A fatherOf B; B hasFather A), and @active and
@passive just don't say that.
I'd be open to proposing a different way of doing this if relation really
can't be changed, especially if it was never meant to do this kind of work.
On Fri, May 30, 2014 at 1:01 PM, Martin Holmes martindholmes@users.sf.net
wrote:
Related
Feature Requests:
#504I think Lou is probably right that relation has been abused by the forcing of RDF semantics upon it. I maintain that it's very useful to be able to encode RDF-style tuples in TEI, as a means of adding semantics to our documents. Should we take a step back and think about developing good, standard ways of doing this?
I wonder a bit about
<link>
, which currently can represent undirected links between resources using only the @target attribute. Possibly it could be augmented to permit typed, directed links too. Then you'd have most of the RDF semantics right there without changing the nature of the element at all.In response to making links directional, my first though was that both
<link>
and<linkGrp>
are att.typed, so it's easy to specify that a link goes in a specific direction. But since @target is a space-separated list of pointers, any directionality would have to depend on the sequence of those pointers; and while that sequence should I think be preserved by an XML parser, that seems rather a fragile thing to me.If that's the case, then specialist attributes on
<link>
and<linkGrp>
would be required too. But then: could you not encode directed links simply using<graph>
and<arc>
? Aren't<graph>
and<arc>
basically just<link>
and<linkGrp>
with directionality?I would say that
<link>
with several @targets defines an undirected linkage between the URIs in those targets—which is a useful thing to be able to do. For directed links, I think we'd need another attribute (call it @source for the sake of argument, even though that's perhaps spoken for). @type may not be quite sufficient for expressing RDF-style properties, because they are always URIs themselves, and @type is data.enumerated, so we'd need a mechanism for mapping types to URIs.Using
<graph>
and<arc>
might be ok, though my impression is that they're conceived of as something more like "GraphViz's Dot language in XML" than as a means to superimpose a graph structure on a TEI document.Surely the important thing is to ensure that whatever means we recommend to represent 'triples' is adequate to the task. E.g. that it allows subject, object, and predicate all to bear URIs; and that it allows triples to nest, i.e. allows a triple itself to serve as object or subject of another triple. The kerfuffle over nomenclature seems to me misplaced: I have no trouble with @active and @passive as means of denoting the party that acts and the party that is acted upon in a given relationship; clearer in fact than the recommended (and now discarded) @from/@to suggestion, perhaps because I am more apt to think in grammatical than in graphical metaphors. IN any case, the discussion seems to have moved beyond \<relation> to consider alternatives, and that seems to me a good thing.
Hi Paul,
Let me attempt to change your mind (with regard to your indifference towards the names for @active and @passive). This is an example lifted from a recently closed ticket (744):
One can't suggest a non-baroque way of interpreting this. What's referenced by @passive is the grammatically active subject of the reconstructed statement. What is referenced by @active is the passive subject. I'm not screaming now only because the colleague next door has a fragile personality.
(Incidentally please note that this also shows a promising path to produce markup-semantic nonsense even if
<relation>
is used strictly for its original purpose. But I can distance myself from that particular use. For encoding triples, I like the proposed<triple>
solution,<arc>
being a potential fallback.)I know, it makes me ill too. I need to pick this back up, but my view has
come to be that since TEI has a fairly full-featured labeled graph
capability, it can represent RDF, though it might require one or two
tweaks, and certainly examples of best-practice.
Relation should be quietly retired back to representing relationships
between people....
On Fri, Mar 13, 2015 at 11:09 AM, Piotr Banski bansp@users.sf.net wrote:
Related
Feature Requests:
#504Are we converging on the idea of proposing a new element <triple> which has exactly the right attributes and content ? We could transition to it by deprecating the use of existing <relation> to denote anything other than interpersonal relations.
I think we may actually be converging on using graph/node/arc with some guidance on how to use them to represent RDF-like triples. I think the only change we’d need is an element to permit the representation of properties on nodes and arcs (now they only have labels). A property element would presumably be the way to do this.
Agreed on deprecating the promiscuous use of relation.
Hugh
Related
Feature Requests:
#504While I'm usually sympathetic to the idea of tweaking slightly an existing element for a purpose very near its semantics, and to thus eschew the process of formalizing a new element, it seems that quite a few tweaks would be needed for
arc
to make it seamlessly take over all the roles that users might want to put it to, having learned that it's meant to handle RDF within the TEI.For one thing, @from must be an URI and can't be absent (we could agree to use from="#blank", but that is a kludge, isn't it). @to must be an URI and can't be a literal. And
<label>
is also used elsewhere, as a literal rather than URI.Perhaps it would be a good idea to try to model a new element close to Turtle syntax, calling it, as suggested above,
<triple>
, and using subject/predicate/object as the attributes, with the appropriate properties. Then it could be seen whether this poor man's RDF suffices for 90%+ uses or whether it should be extended, but then the extension process would be very local and easy to control (easier than handling all the legacy).if you invent <triple>, you’re gaining no more power than embedding RDF/XML in TEI. so why not do so explicitly?
--
the onlie begetter of <relation>-as-rdf
Or that, then...