Note that while attrs are indexed by key:value they aren't indexed by
value:key (currently). So you can't enumerate all inbound edges
efficiently.

I should also mention that depending on how strongly you want to keep
your custom graph separate from other usage of attrs (by perkeep
itself, etc), you may want to prefix your keys, like so:

   g:refutes


On Tue, Feb 19, 2019 at 12:48 AM Eric Drechsel <[email protected]> wrote:
>
> Late reply :)
>
> Of course there are lots of ways to model graphs, in any data store.
>
> Assuming you want labeled edges, you could create a claim on node A setting a 
> property whose name is the label and value is the hash of the target.
>
> This would allow you to use the builtin index to walk forward (by listing 
> attrs set on the current node) as well as backward (using the attr:key:value 
> search operator).
>
> For more advanced querying/traversal, you could slurp subsets of the data 
> into a dedicated graph db such as DGraph, the mentioned Indra, etc.
>
> I would probably stop short of modeling the edges as nodes, although it is 
> certainly a viable option if you really need it, but mathematical graphs 
> don't let you have edges connecting edges. If you really want to talk about 
> the edges, you could create your own custom metadata objects that reference 
> the hash of the claim that adds an edge attr. But you are far into the weeds 
> at that point.
>
>
> On Fri, Oct 19, 2018 at 5:37 AM Dan Kortschak <[email protected]> 
> wrote:
>>
>> Hi,
>>
>> I want to be able to store graph-like relationships between files and
>> permanodes in a perkeep. The edges in the case are directed from one
>> file or permanode to another and may have claims made about their
>> existance or validity, and annotations after they have been created.
>>
>> Ideally I'd like also to be able to search for relationships and
>> extract graphs from the perkeep based on these relationship (long term
>> goal).
>>
>> What would be a sensible approach to achieving this? The two that I
>> have thought of are either claims on the from node pointing to the to
>> node and vice versa, or adding an additional permanode that behaves as
>> a link between the from and to nodes. The second approach intuitively
>> seems more flexible and amenable the kinds of things I want to do with
>> them.
>>
>> Does this seem reasonable?
>>
>> By way of background, I'm attempting to construct a science lab
>> notebook system that keeps experimental results, result interpretations
>> and other notes in a way that can be used to store and extract argument
>> graphs for research projects.
>>
>> thanks
>> Dan
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Perkeep" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> best, Eric
> eric.pdxhub.org
>


-- 
best, Eric
eric.pdxhub.org

-- 
You received this message because you are subscribed to the Google Groups 
"Perkeep" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to