[okfn-dev] Design question for SNA tool "grano"

Fri Jan 20 00:09:16 UTC 2012

Sounds like you want to go with per-network schemas. I can see why, I can
only imagine a global schema being highly general and unstructured, full of
data blobs which can't really be queried...

I think to make sense of this I'd need to understand:
* How global is global? Do you intend every user to fire up their own
instance or will we run one central point (something like FluidInfo?)
* Can you describe a concrete use case?

I guess a global schema is a huge advantage if you're going to be querying
multiple graphs or between graphs. Doesn't look like that's something
people would do though.

On Wed, Jan 18, 2012 at 7:21 PM, Friedrich Lindenberg <
friedrich.lindenberg at okfn.org> wrote:

> Hi all,
>
> [[Rufus mentioned that he's considering to rename this list okfn-labs
> to discuss more random OKF hackyness. In this spirit, here is a
> brutally off topic discussion:]]
>
> I've recently begun hacking on Grano, a web-based social network
> analysis tool [1]. In Grano, there are three key domain objects:
> Network, Entity and Relation (i.e. Graph, Node, Edge). Both entities
> and relations can be typed, which means there is a dynamically
> generated, joined table that has a certain schema (e.g. [2]),
> extending the core properties of a thing or link. The idea of a
> network is to partition the graph with access control, e.g. a reporter
> could make a network and store actors in a story, then later share it.
>
> Now the questions are:
>
> * are schemas per-network or global? The global option allows you to
> merge networks more easily, but also means you have a namespace that
> can get polluted (maybe the first person to define "Person" as a
> schema type is doing this for a very specific use case). In the end,
> when you do global schemas you end up being somewhat more like the
> linked data idea of common ontologies, and I'm not sure that's a good
> thing.
>
> * same for entities and relations: they do have "root tables", i.e.
> "entity" and "relation". Should these also be name-spaced per network
> in separate tables (like openspending entries)? At the moment, the
> requirement for all relations to remain within the graph is just
> enforced in validation, and that's also nice (in the same way it was
> nice in OS, which went horribly wrong - but here it may actually be
> the point).
>
> Cheers,
>
>  - Friedrich
>
> [1] http://github.com/pudo/grano - README may be helpful. In general,
> this is probably just a dummy prototype, but still: it may go
> somewhere.
> [2] https://github.com/pudo/grano/blob/master/grano/test/helpers.py
>
> _______________________________________________
> okfn-dev mailing list
> okfn-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/okfn-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/okfn-labs/attachments/20120120/d4479d89/attachment-0002.html>