3 ms·

1. We do support framing. Our documents are defined using a special superclass called "terminus:Document". Anything in the downward closed DAG up to another "te

1. We do support framing. Our documents are defined using a special superclass called "terminus:Document". Anything in the downward closed DAG up to another "terminus:Document" is considered part of that document. You can ask for some number of unfoldings of the internal documents by passing a natural number - in which case you will frame the underlying documents. We might extend this framing to allow more sophisticated approaches later if there is interest. 2. We have not performed benchmarks against RedisGraph. We intend to do benchmarks in the future but are currently focusing on collaboration features rather than raw speed. I had just come up with some methods of using GPUs to speed up graph search when I saw the RedisGraph whitepaper and that they had already done it. I have to admit I was more than a little jealous! It's a good idea. We'll look at the approach again in the future - our next steps are exposing CLP(fd) in our query language.

chekovcodes 6y ago
haha Gavin - same answer, same time almost the same content. We have to get out more. Oh crap...
laurencerowe 6y ago
So if I understand correctly, unfolding one level would embed the referenced documents in the result one level down, two would also embed the documents referenced in the root document's referenced documents, etc. I think it's definitely worth supporting differing depths of reference embedding along different paths. Ideally though you want want to select which properties are included as when you get to several levels of embedding the resulting document is very large and often you only need a subset of properties expanded for the embedded documents. Additionally it can be very helpful to embed along reverse references (parent.children from the reference stored as child.parent.) Concrete example, take this page on a scientific data portal: https://www.encodeproject.org/experiments/ENCSR807BGP/ https://www.encodeproject.org/experiments/ENCSR807BGP/ The JSON-LD document representing that object itself is: https://www.encodeproject.org/experiments/ENCSR807BGP/?format=json&frame=object https://www.encodeproject.org/experiments/ENCSR807BGP/?forma... and many reference paths are expanded to generate the JSON required to construct the UI: https://www.encodeproject.org/experiments/ENCSR807BGP/?format=json https://www.encodeproject.org/experiments/ENCSR807BGP/?forma... (this is larger than it needs be as the entire referenced document is embedded rather than just the necessary proeperties.) While pre-generating the deeply embedded document means fetching it is fast, as the site has grown keeping them up to date becomes challenging so I've been looking at options for embedding dynamically.
- ggleason 6y ago
  "So if I understand correctly, unfolding one level would embed the referenced documents in the result one level down, two would also embed the documents referenced in the root document's referenced documents, etc." That's correct. "I think it's definitely worth supporting differing depths of reference embedding along different paths." Yeah, path unfoldings were something we were thinking about but ended up on our very tall stack of things we want to do. You can generally get around it just by calling the get_document API on the client end from javascript, although it is true this will be much slower.

chekovcodes 6y ago

haha Gavin - same answer, same time almost the same content. We have to get out more. Oh crap...

laurencerowe 6y ago

So if I understand correctly, unfolding one level would embed the referenced documents in the result one level down, two would also embed the documents referenced in the root document's referenced documents, etc. I think it's definitely worth supporting differing depths of reference embedding along different paths. Ideally though you want want to select which properties are included as when you get to several levels of embedding the resulting document is very large and often you only need a subset of properties expanded for the embedded documents. Additionally it can be very helpful to embed along reverse references (parent.children from the reference stored as child.parent.) Concrete example, take this page on a scientific data portal: https://www.encodeproject.org/experiments/ENCSR807BGP/ https://www.encodeproject.org/experiments/ENCSR807BGP/ The JSON-LD document representing that object itself is: https://www.encodeproject.org/experiments/ENCSR807BGP/?format=json&frame=object https://www.encodeproject.org/experiments/ENCSR807BGP/?forma... and many reference paths are expanded to generate the JSON required to construct the UI: https://www.encodeproject.org/experiments/ENCSR807BGP/?format=json https://www.encodeproject.org/experiments/ENCSR807BGP/?forma... (this is larger than it needs be as the entire referenced document is embedded rather than just the necessary proeperties.) While pre-generating the deeply embedded document means fetching it is fast, as the site has grown keeping them up to date becomes challenging so I've been looking at options for embedding dynamically.

ggleason 6y ago
"So if I understand correctly, unfolding one level would embed the referenced documents in the result one level down, two would also embed the documents referenced in the root document's referenced documents, etc." That's correct. "I think it's definitely worth supporting differing depths of reference embedding along different paths." Yeah, path unfoldings were something we were thinking about but ended up on our very tall stack of things we want to do. You can generally get around it just by calling the get_document API on the client end from javascript, although it is true this will be much slower.