Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#504 Replace @active and @passive on relation with @from and @to

AMBER
open
None
5(default)
2015-03-13
2014-04-21
Hugh A. Cayless
No

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).

Related

Feature Requests: #504

Discussion

  • Piotr Banski
    Piotr Banski
    2014-04-21

    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:

      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".


      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/

       

      Related

      Feature Requests: #504

      Attachments
  • James Cummings
    James Cummings
    2014-05-19

    • assigned_to: Hugh A. Cayless
     
  • James Cummings
    James Cummings
    2014-05-19

    Assigning to Hugh Cayless to remind council of this ticket and gather consensus for changes.

     
  • BODARD Gabriel
    BODARD Gabriel
    2014-05-30

    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?

     
  • Martin Holmes
    Martin Holmes
    2014-05-30

    +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?

     
  • Lou Burnard
    Lou Burnard
    2014-05-30

    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?

     
  • Lou Burnard
    Lou Burnard
    2014-05-30

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

     
  • Martin Holmes
    Martin Holmes
    2014-05-30

    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.

     
  • Lou Burnard
    Lou Burnard
    2014-05-30

    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.

     
  • Martin Holmes
    Martin Holmes
    2014-05-30

    <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:

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


      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/

       

      Related

      Feature Requests: #504

  • 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.

     
  • Martin Holmes
    Martin Holmes
    2014-06-06

    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.

       
  • Paul Schaffner
    Paul Schaffner
    2014-07-02

    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.

     
    • Piotr Banski
      Piotr Banski
      2015-03-13

      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.)

       
      • 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 <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.)


        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/

         

        Related

        Feature Requests: #504

        Attachments
  • Lou Burnard
    Lou Burnard
    2015-01-11

    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.

     
    • 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 <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.

      [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

       

      Related

      Feature Requests: #504

  • Piotr Banski
    Piotr Banski
    2015-03-13

    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).

     
    • 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

       
      • Piotr Banski
        Piotr Banski
        2015-03-13

        Or that, then...