Queries

[ahdinosaur]

this issue is dedicated to how we represent queries, for both humans and machines to understand.

previous discsusions:

• https://github.com/valueflows/agent/issues/5
• https://github.com/valueflows/agent/pull/37#issuecomment-147740739

extracting my favorite parts:

@simontegg: 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.

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.

---

@ahdinosaur: 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.

---

@elf-pavlik: For queries like label: 'People who steward {target}' I recommend checking out

• http://linkeddatafragments.org/
• http://www.hydra-cg.com/spec/latest/triple-pattern-fragments/

Or for simple traversals, my collection proposal based on ldp:DirectContainer and brainstorming in Hydra group

[elf-pavlik]

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"

Have you played with http://client.linkeddatafragments.org/ ? (if not try dropdown after "…or pick an example query")

More details:

• http://linkeddatafragments.org/in-depth/
• http://linkeddatafragments.org/publications/

[elf-pavlik]

https://github.com/valueflows/agent/issues/38#issuecomment-149365227

Holodex plans to remove the separation between member and parent / child, since in most literature on holons it's the same relationship type, and that way things are simpler.

Since this would work on any sub classes of Agent, how do you add distinction between queries like

• "Networks that Loomio affiliates with"
• "Groups that Mikey participates in"

[elf-pavlik]

Regarding https://github.com/valueflows/resource/issues/9#issuecomment-149061235

If many independently different properties, use exactly the same label for query e.g

• dex:maintains- "Resources which {subject} maintains"
• verb:maintains- "Resources which {subject} maintains"
• foo:isMaintainerOf- "Resources which {subject} maintains"

how UI will deal with showing at the same time queries for dex:maintains, verb:maintains and foo:isMaintainerOf?

[ahdinosaur]

regarding queries, i'm interested in slowly migrating towards the spirit of Linked Data Fragments, i.e. a query is a set of triples with variables. there is still an important problem i see missing a solution which is: how do we create an interactive interface to display and manipulate those queries, although a dropdown from "label" -> query as linked is a good first step.

Since this would work on any sub classes of Agent, how do you add distinction between queries "Networks that Loomio affiliates with" and "Groups that Mikey participates in"

if we expand those to (psuedo-code) triple pattern fragments, the first is:

[{
  "subject": "result",
  "predicate": "rdf:type",
  "object": "dex:agentTypes/network"
}, {
  "subject": "dex:agents/loomio",
  "predicate": "dex:relationshipTypes/affiliates",
  "object": "result"
}]

the second:

[{
  "subject": "result",
  "predicate": "rdf:type",
  "object": "dex:agentTypes/group"
}, {
  "subject": "dex:agents/mikey",
  "predicate": "dex:relationshipTypes/participates-with",
  "object": "result"
}]

right?

how UI will deal with showing at the same time queries for dex:maintains, verb:maintains and foo:isMaintainerOf?

i reckon we de-dupe the relationship types, while preferring more local types (those closest to your agent namespace), and then use the type labels to generate query labels. i don't think there will ever be a clean way to do this since semantics are subjective (e.g. even if the relationship types are owl:equivalentProperty, which label do we prefer?).

[elf-pavlik]

'(psuedo-code) triple pattern fragments' make sense and LevelGraph supports similar searches

Still one very unlikely would attach them to definitions of properties, commonly used properties usually simply don't 'know' about existence of some particular custom (sub)types defined in a data set published somewhere on the web. If those common properties use common 'high level' types in their rdfs:domain and rdfs:range definitions. One could possibly generate such queries based on those definitions.

i reckon we de-dupe the relationship types, while preferring more local types (those closest to your agent namespace)

Let's say I will deploy holodex on holodex.apps.wwelves.org, will i need to configure it with some kind of cascading hierarchy of namespaces? if so, do you already work on implementing such configuration feature?

[ahdinosaur]

related link dump: "UI Pattern: Natural Language Form"

[almereyda]

We have moved the ValueFlows organization from GitHub to https://lab.allmende.io/valueflows.

This issue has been closed here, and all further discussion on this issue can be done at

https://lab.allmende.io/valueflows/forum-valueflo-ws/-/issues/26.

If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there.