Closed TEITechnicalCouncil closed 8 years ago
This issue was originally assigned to SF user: hcayless Current user is: hcayless
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".
Original comment by: @bansp
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:
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 inherentdirectionality of "from" and "to".
- [feature-requests:#504] http://sourceforge.net/p/tei/feature-requests/504/ Replace
@active
and@passive
on relation with@from
and@to
*Status: open Group: AMBER Created: Mon Apr 21, 2014 03:39 PM UTC by Hugh A. Cayless Last Updated: Mon Apr 21, 2014 03:39 PM UTC Owner: nobody
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 relationhttp://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-relation.htmlelement 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 vocabularyhttp://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-arc.htmlfor representing graphs http://www.tei-c.org/release/doc/tei-p5-doc/en/html/GD.html#GDGR:@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
).Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/tei/feature-requests/504/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Original comment by: @hcayless
Original comment by: @jamescummings
Assigning to Hugh Cayless to remind council of this ticket and gather consensus for changes.
Original comment by: @jamescummings
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?
Original comment by: @gabrielbodard
+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?
Original comment by: @martindholmes
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)
Original comment by: @lb42
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?
Original comment by: @sebastianrahtz
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!
Original comment by: @lb42
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 to
redo 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.
Original comment by: @sebastianrahtz
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.
Original comment by: @martindholmes
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.
Original comment by: @lb42
<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.
Original comment by: @martindholmes
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:
's `@from` and `@to` can hold only one pointer, but 's `@active` and `@passive` can hold multiple pointers. If the objective is to represent RDF triples, then and are precisely what is required; if the objective is to model complex relationships among humans, then looks to me to be more powerful. It would be trivial to ## transform -based structures into a graph, though. - [feature-requests:#504] http://sourceforge.net/p/tei/feature-requests/504/ Replace `@active` and `@passive` on relation with `@from` and `@to`* _Status:_ open _Group:_ AMBER _Created:_ Mon Apr 21, 2014 03:39 PM UTC by Hugh A. Cayless _Last Updated:_ Fri May 30, 2014 04:54 PM UTC _Owner:_ Hugh A. Cayless 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 http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-relation.html 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 http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-arc.html for representing graphs http://www.tei-c.org/release/doc/tei-p5-doc/en/html/GD.html#GDGR: `@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`). Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/tei/feature-requests/504/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Original comment by: @hcayless
I 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.
Original comment by: @hcayless
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?
Original comment by: @martindholmes
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.
Original comment by: @hcayless
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
Original comment by: @pfschaffner
Are 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.
Original comment by: @lb42
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
On Jan 11, 2015, at 10:24 , Lou Burnard louburnard@users.sf.net wrote:
Are we converging on the idea of proposing a new element
which has exactly the right attributes and content ? We could transition to it by deprecating the use of existing to denote anything other than interpersonal relations. [feature-requests:#504] http://sourceforge.net/p/tei/feature-requests/504 Replace
@active
and@passive
on relation with@from
and@to
Status: open Group: AMBER Created: Mon Apr 21, 2014 03:39 PM UTC by Hugh A. Cayless Last Updated: Sat Aug 16, 2014 05:17 AM UTC Owner: Hugh A. Cayless
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 http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-relation.html 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 http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-arc.html for representing graphs http://www.tei-c.org/release/doc/tei-p5-doc/en/html/GD.html#GDGR:@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
).Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/tei/feature-requests/504/ https://sourceforge.net/p/tei/feature-requests/504 To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ https://sourceforge.net/auth/subscriptions
Original comment by: @hcayless
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):
<relation type="CRM"
name="P87_is_identified_by"
active="http://id.clarosnet.org/places/ashmol/placecode/22584"
passive="http://id.clarosnet.org/places/ashmol/placename/orvieto"/>
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.)
Original comment by: @bansp
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:
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):<relation type="CRM" name="P87_is_identified_by" active="http://id.clarosnet.org/places/ashmol/placecode/22584" passive="http://id.clarosnet.org/places/ashmol/placename/orvieto"/>
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
is used strictly for its original purpose. But I can distance myself from that particular use. For encoding triples, I like the proposed solution, being a potential fallback.)
- [feature-requests:#504] http://sourceforge.net/p/tei/feature-requests/504 Replace
@active
and@passive
on relation with@from
and@to
*Status: open Group: AMBER Created: Mon Apr 21, 2014 03:39 PM UTC by Hugh A. Cayless Last Updated: Sun Jan 11, 2015 03:24 PM UTC Owner: Hugh A. Cayless
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 http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-relation.html 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 http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-arc.html for representing graphs http://www.tei-c.org/release/doc/tei-p5-doc/en/html/GD.html#GDGR:@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
).Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/tei/feature-requests/504/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Original comment by: @hcayless
While 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).
Original comment by: @bansp
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
Original comment by: @sebastianrahtz
Or that, then...
Original comment by: @bansp
Original comment by: @hcayless
Decision at May 2015 Council Meeting: give up on "fixing" the relation element and instead provide guidance on using TEI's existing graph element and cohorts to represent RDF-style data in a TEI document. Closing this and will open a new FR.
Original comment by: @hcayless
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
).Original comment by: @hcayless