queries

[ahdinosaur]

we've been working on a data structure for how we represent queries in the url (holodex/holodex#63), i reckon it's about time we moved this data structure into the vocab proper, so here's a space for that conversation.

/cc @simontegg

[ahdinosaur]

progress has been done following this in enspiral-data/linkTypes.csv.

@simontegg assuming we migrate to only having agentTypes, agents, relationshipTypes, and relationships, what data do you think we need to support queries? or more specifically, could you explain labels and queryLabels and the difference between them?

[simontegg]

some background first:

Holodex is data-centric, meaning that it works with an underlying unified dataset of people, groups and relationships. This makes Holodex distinct from applications like metamaps and kumu where users compose maps directly, but a person on one map is not linked to the same person in another map. When the user adds public data to Holodex they add to the Global General Graph ( a data commons )

We assume that since the entire dataset (the Graph) will be very large this makes viewing and navigating the all of the people groups and relationship in a single view overwhelming and infeasible.

The first solution we came upon was to make the general navigation of the graph constrained to a single agent at a time (the contextAgent )

We assume that a further solution to the above problem is for the user to query, view and combine particular slices of the Graph, queries, depending on what they're interested in. Graph queries (that I'm familiar with) have two attributes that make for a good potential solution, technically, and usability-wise:

• a human readable description
• routine to implement with a graph database

Graph queries can take the form of a known entity, a known relationship, and an unknown set of entities - "People [unknown set of entities] who live in [known relationship] Wellington [known entity].

[they might also be two known entities and an unknown set of relationships "Relationships that connect Simon and Wellington"]

a queryLabel then is a natural language description of a query. Because queries are constructed on the fly by users we can't hardcode all possible queryLabels, but because we're largely dealing with people and groups it seems feasible to generate them from templates. In English generally something like:
[agentType :plural] -- that [relationship :verb] -- [entity] - (known), or
[agentType :plural] -- that -- [entity] - (known) -- [relationship :verb]

"People who steward Simon"
"Groups that Mikey belongs to"

By using these labels in an autocomplete feature I assume that this will be a usable way for performing graph queries (see FB). Once executed they provide a clear description of what the user is viewing.

In the current setup I have attached these queryLabel templates to the link as this seems like there natural home. I was imagining that when users create a new relationship they would be prompted to compose a description of Agents that perform the relationship or have the relationship performed on them.

[bhaugen]

On Sun, Aug 16, 2015 at 7:26 PM, simontegg notifications@github.com wrote:

When the user adds public data to Holodex they add to the Global General Graph ( a data commons )

Yes! That's we want!

[ahdinosaur]

wow, great recap @simontegg. 👍

i think i understand what a queryLabel is now. and with that in mind, i imagine a label is the text that would appear when you hovered over a relationship, e.g. "Mikey stewards Simon" or "Mikey belongs to Enspiral Craftworks".

another piece worth mentioning is composability, as queries must inherently compose. currently we only compose the graph routines as distinctly separate objects, and don't even try to compose the human descriptions, which seems to work just fine. on this topic, my current train of thinking is how levelgraph does composable querying.

I was imagining that when users create a new relationship they would be prompted to compose a description of Agents that perform the relationship or have the relationship performed on them.

yeah, i've been wondering if in the new vocab draft, a RelationshipType should have sourceAgentType, targetAgentType, and contextAgentType that describe the types of agents that may be involved in such a relationship type. this is a path towards agentType (being | including) composable queries for which agents are of that type, not sure if it's a good idea.

[fosterlynn]

yeah, i've been wondering if in the new vocab draft, a RelationshipType should have
sourceAgentType, targetAgentType, and contextAgentType that describe the types of
agents that may be involved in such a relationship type. this is a path towards agentType
(being | including) composable queries for which agents are of that type, not sure if it's a
good idea.

@ahdinosaur We talked about that early on when doing Agent ourselves, and decided we didn't really need it, but it still seems like a perfectly fine vocab addition. It would give people constraints on entry; and I can see it could help on the query creation side as you suggest. A note - we would need to explicitly support Agent as supertype of Person and Organization, because some relationships could be with any agent type.

[ahdinosaur]

btw, work in progress vocabs for QueryType and Query.

[ahdinosaur]

related comment by @elf-pavlik: #37 (comment)

[ahdinosaur]

superseded by https://github.com/valueflows/valueflows/issues/67