Consider unabbreviated field names for node labels and edge fields (lbl, sub, obj)

[cmungall]

Moved discussion from #15 from @cmpich

Consider lbl->label, sub->subject, obj->object, pred->relation/predicate

Pros:

• correspond to terms used in rdf/rdfs vocabulary
• greater clarity

Cons:

• breaks compatibility with js code that accepts bbop-graphs, and with software that produces bbop-graphs (e.g. scigraph)
• increased size of payload

The compatibility is a larger concern. If payload is a concern there are better ways to decrease size of payload for simple bbop-graphs and in particular edge lists:

• compression (bigger gains for larger subgraphs?)
• use of protobuf, bson etc instead of json
• a more compact graph representation

Consider the owlsim internal representation: each node is assigned an integer, sets of edges indexed by predicate, where each edge represented as an integer pair. This reduces a go bbop graph from 11m to 3.6m (the majority of which is labels, the graph itself is encoded in <1m).

This compact representation would be something negotiated between client and server, with the default being the human-readable but more voluminous form.

[cmungall]

See also comments from @kltm on https://github.com/owlcollab/owltools/pull/178#issuecomment-290822894

[kltm]

Reading through this, I would say that actually size is worth considering on it's own in an over-the-wire format like this. While servers can do nice things with compression on the fly, without it, in our own tests, it did significantly slow down clients interacting with the data.