SDA SE Wiki

• nodetype(nodetype:String)
• edgetype(edgetype:String,source:nodetype,target:nodetype)
• Issue: A nodetype/edgetype is a unique atom (Number or String) in Prolog. What's the best representation in Java (Integer, String, enumeration, Class, …)?
• Issue: Does it make sense to define labeltypes and include them into the edgetype specification? Currently I feel that arbitrary Strings are sufficient but I might just not be able to anticipate future needs. –GK
  • Issue: Should we explicitly represent “aggregationtype”? Aggregations are just a special kind of edges. Thus we could make aggregations explicit by adding aggregationtype(aggregationtype:edgetype). Currently, I think it is not neccessary. But I might be wrong. –GK

• node(id:nodeid, type:nodetype, label:string)
• edge(id:edgeid, type:edgetype, label:string, source:nodeid, target:nodeid)Why do we need a edgeid? – TR 03.11.05
• within(id:edgeid, type:edgetype, label:string, outer:nodeid, inner:nodeid)
• Issue: Do we need “within” or is it just like any other edge? From a formal point of view the edgetype information is sufficient to distinguish aggregations from other nodes. Thus it would be sufficient to have “edge” information. Are there any practical considerations that might recommend to keep “within” separate?

I would prefer an edge with the node type 'parent'. If we use within/5 instead of the parent edge, what's the label for? – TR 04.11.05

• property(node:nodeid, propertyType(…var args…))
  
• propertyType(“file”, 'Eclipse style full qualified file path':String)
• propertyType(“position”, offset:int, length:int)
  • offset:int –> starts at, including
  • length:int –> including
• Property association
  • file: with aspects, CTs and clauses
  • position: every node from root to leaf (including)

• Prolog
  • predicate - common parent of clauses with same definition module and head term.
  • clause - definition of a single clause. Child of a predicate-node.
  • literal - the head of a clause is a literal. The body of a clause is a conjunction of literals. The parent node of a literal is a clause.
    • I am not completly sure about what should be reported as a literal. Currently i am using a table that associates the typical set of control/meta predicates (','/2, ;/2, →/2, …) to the respective argument positions on which we expect more literals. To these arguements the same check is recursively applied. So e.g. for ','/2 we check both arguments wheras for catch/3 we only need to check the first and the third argument. In addition each entry in the table contains a flag that determines, wether the respective goal should itself be reported as a literal. For instance this is the case with forall/2 while things as basic as ','/2 are omitted. Please tell me if you need other behaviour.
  • term - every prolog term that is not a literal. (atoms, lists, compounds). A term is a childnode of another term or of a literal.
• CT
  • ct - a clause that has no body (i.e. a fact) and that has a head term with the principal functor “ct/3”. Note that this nodes are created IN ADDITION TO the respective clause nodes. If an other behaviour is desired please tell me.
  • condition - The second argument of a ct/3 fact.
  • action - The third argument of a ct/3 fact.
  • ctliteral -
• logicaj
  • Prolog and CT nodes will be provided by the PDT –lu

• Prolog
  • clause - from a predicate node to clause nodes
  • head_literal - from a clause node to a literal node
  • body_literal - from a clause node to literal nodes
  • argument_term - from a literal node to term nodes

Bashar: Define the entire Morph stuff on the Java side, possibly with suitable Preference options.

• morph(nodeOrEdgeType,morphDisplayType,morphInteractionType)
• Issue: Enable dynamic change of morph display and behaviour when any of the above morph infos is changed.

???

• List of applicable commands???
• Do they need to be parametrized? Hopefully not.