map viewer - filter menu does not communicate with tags

[josefkreitmayer]

@keikreutler I hope, this here is the right place and right way to adress that issue / feedback or general information on the development of the map viewer.

Currently the Sub-Categories just open, and by click close again. I am quite sure you are aware of it, and maybe I just see an intermediary stage and want to ask, if you need any further information or changes in order to fully implement the filter sets into the menu?

@species is there full clarity on your side?

[keikreutler]

@josefkreitmayer Thanks for the feedback. Do you mean the filters don't
currently show/ hide points on the map? They don't correspond to the data
currently as far as I can see, so until there's corresponding data the
actual function won't work. Correct me if I'm wrong re the data @species!

On Mon, May 30, 2016 at 7:10 PM, josefkreitmayer notifications@github.com
wrote:

@keikreutler https://github.com/keikreutler I hope, this here is the
right place and right way to adress that issue / feedback or general
information on the development of the map viewer.

Currently the Sub-Categories just open, and by click close again. I am
quite sure you are aware of it, and maybe I just see an intermediary stage
and want to ask, if you need any further information or changes in order to
fully implement the filter sets into the menu?

@species https://github.com/species is there full clarity on your side?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#23, or mute
the thread
https://github.com/notifications/unsubscribe/AGNJTuHQRsQJUpR5SVueNU9V8V1HNPgSks5qG25bgaJpZM4IqEj7
.

[josefkreitmayer]

@keikreutler
it seems, that there is general a break in the connection to the data.

• All popups show the same data
• the filter-sub-categories close again, when clicked
• There should be at least around 50 points in the data, that are tagged with the respective types_of_initiatives.

@species ordered me to go on and put further tags where they are not set yet. I will do that in the next hours.
@keikreutler could you see if you can connect the data with the popups and the filter categories meanwhile?

[keikreutler]

Hi josef,

The current data is sample data, so other than the 'type_of_initiatives'
attribute, there isn't a direct correlation between the data's categories
and the filter attributes, i.e. there's a filter "Community Gardening",
with no matching dataset either by ID or string, though there are a few
listed as "Community Garden", and some of them don't crossover at all, i.e.
'Reduce, reuse, repair, recycle' main filter category has no related
datapoints. Does this make it clearer?

The types of initiatives tag will be in the secondary menu, so I can hook
that up, but for right now most of the popup data on the map is placeholder
content while it's being styled and in waiting for the correlating data.

On Tue, May 31, 2016 at 12:27 PM, josefkreitmayer notifications@github.com
wrote:

@keikreutler https://github.com/keikreutler
it seems, that there is general a break in the connection to the data.

• All popups show the same date
• the filter-sub-categories close again, when clicked
• There should be at least around 50 points in the data, that are
  tagged with the respective types_of_initiatives.

@species https://github.com/species ordered me to go on and put further
tags where they are not set yet. I will do that in the next hours.
@keikreutler https://github.com/keikreutler could you see if you can
connect the data with the popups and the filter categories meanwhile?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#23 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AGNJTqwj4rudY5QpSCFldqav0Lcsxy9xks5qHGGLgaJpZM4IqEj7
.

[species]

Hi @keikreutler ,

the connection between the taxonomy.json and the data points are via the data point's "type_of_initative" attribute, and the elements in the taxonomy.json which are "instance_of" "Q13742#TypeOfInitiative".
The "type_of_initiative_tag" in the taxonomy.json element holds the "value" attribute, which corresponds to the data point's "type_of_initative" attribute.
The "type_of_initiative_tag" elements in the taxonomy.json carry the attribute "subclass_of", and therefore are a member of one of the categories.

I've drawn a small chart visualizing the structure of the taxonomy.json file:

Source: https://github.com/TransforMap/import-flows/blob/master/charts/SSEDAS/datastructure_taxonomy.json.pdf

[keikreutler]

Is it the intention that eventually the taxonomy.json URIs will provide
json collections of POI which fall under that category?

On Tue, May 31, 2016 at 1:04 PM, Michael Maier notifications@github.com
wrote:

Hi @keikreutler https://github.com/keikreutler ,

the connection between the taxonomy.json and the data points are via the
data point's "type_of_initative" attribute, and the elements in the
taxonomy.json which are "instance_of" "Q13742#TypeOfInitiative".
The "type_of_initiative_tag" in the taxonomy.json element holds the
"value" attribute, which corresponds to the data point's
"type_of_initative" attribute.
The "type_of_initiative_tag" elements in the taxonomy.json carry the
attribute "subclass_of", and therefore are a member of one of the
categories.

I've drawn a small chart visualizing the structure of the taxonomy.json
file:

[image: screenie_taxonomy json]
https://cloud.githubusercontent.com/assets/2196350/15683413/83df95b8-2762-11e6-851b-fcd4e53e9a88.png

Source:
https://github.com/TransforMap/import-flows/blob/master/charts/SSEDAS/datastructure_taxonomy.json.pdf

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#23 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AGNJTh_L83OSahQF7yq02GKuYrSbGXCXks5qHGougaJpZM4IqEj7
.

[josefkreitmayer]

Have @species on the phone. Here in Austria it is 19:45 and he is about to start his classical dancing classes (one of his most beloved hobbies). He will be available again in 2 hours.

His answer to your question:

No, this is not the intention. The intention of the HTTP URIs is to act as identifiers for each element in the taxonomy.json.

Does that help?

[keikreutler]

Okay. This structuring seems unnecessarily complex from a UI perspective. I
will work as steadily as I can, and be available to explain in detail why
tomorrow after 5pm CET to speak.

On Tue, May 31, 2016 at 1:43 PM, josefkreitmayer notifications@github.com
wrote:

Have @species https://github.com/species on the phone. Here in Austria
it is 19:45 and he is about to start his classical dancing classes (one of
his most beloved hobbies). He will be available again in 2 hours.

His answer to your question:

No, this is not the intention. The intention of the HTTP URIs is to act as
identifiers for each element in the taxonomy.json.

Does that help?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#23 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AGNJTgie1O9IpJtAY61XpzqboZW2PGC1ks5qHHMygaJpZM4IqEj7
.

[josefkreitmayer]

Maybe @species can explain some reasoning behind the complexity of the structure lateron, or by tomorow.
Have a good work process. Speaking tomorrow.

[gandhiano]

I also don't understand the logic of this structuring, and why we are deriving so much away from the (simplifying) idea of pointing simply to filter objects (which then point simply to selected objects, based on attributes such as UUID, tags, etc.)

So, my question is: what value does it bring to have this complex and rigid hierarchical organization of types of initiative, categories and subcategories? Aren't we better with bringing the matching logic beyond the filter object, so that the user has a very simple way of shaping their filters (and from there build any categories, subcategories, etc. structure)?

[josefkreitmayer]

As far as I understand, the structure presented in the taxonomy.json is based on the structure the wikibase exports will provide, which is the database for the filtersets.

[species]

Okay. This structuring seems unnecessarily complex from a UI perspective.

From an UI perspective, it is, I agree.

The reason for this scheme: It is the format data is returned from a SPARQL endpoint. This is Linked Open Data! With this format we can build arbitrary taxonomies/ontologies. You can find an example visualisation of this data format (as used by Wikidata) here:

https://angryloki.github.io/wikidata-graph-builder/?property=P279&item=Q430&mode=reverse

[gandhiano]

I understand that the queries are complex. But what I mean is, based on our conversations on Berlin, is that @keikreutler and any end-user should be able to use an API endpoint that is simply a filter (query) object. The complexity of the data model inside that object should not play any role in the map display, as it belongs to the realm of the filter/query development and is articulated by other tools (currently wikibase).

[species]

Hi @gandhiano ,

I think you confuse client-side filters with server-side filters in this discussion.
For the map on the main SUSY website, ALL data should be displayed at first, and then filtered on the client-side, if the user clicks any of the filters. It would not make sense to fetch a part of the data (which is already present in the browser) again, when filters (which hide all non-matching pois) are applied.

Of course, later on it should be possible for the partners to create filters for their own website, which are in turn used as a server-side filter for populating the different maps on the partner website.

[gandhiano]

What would be the advantage of building filters both on the client and the server? From an engineering perspective, I feel we just add a huge amount of work and complexity, which can be simplified by having the API taking care of everything (by pointing e.g. to filter/UUID, which would throw a json of points).

In this scenario, the landing view would just be a very simple all-inclusive filter, where all items tagged with SSEDAS would appear. Clicking on another category would be simply pointing to another filter UUID, fetching the json and displaying the points/geometries on a map. It's universally usable and simple to build a multitude of read or read-write interfaces.

There may be a small overhead on this, because you may need to load all the points, but on the other hand servers are optimized to process and you also allow that users with slower computers (and we are here addressing a pretty global audience) have a better navigation experience, than if their CPUs need to be processing thousands of geometries.

If we really want to load full sets and then trim them out without loading new sets of POIs (which for me seems a very particular use case for the SSEDAS project, and which actually contributes for atomization of maps, the exact contrary purpose of Transformap), then lets engineer it better. It makes no sense to waste the development time of @keikreutler, which is needed for providing a good UX, in understanding complex data models and processing. And just like her, we want other users of the Transformap API to have their life made easy, so that people can build many maps in many places.

So, the most outstanding question is: can't we simply have a filter endpoint that throws out a json of points, and associate each category (and the landing view) with the respective filters you build on wikibase?

[almereyda]

I should draw an image of the testbed's stack right now, and reintroduce questions of community ownership (of both the processes and produce) to this discussion, but feel this conversation is only revealing again a conceptual incommensurability we have been employing all along.

To squeeze the pressure from ongoing debate, and take up its space, we could proactively reeavulate

• the resources available and their allocation to bring the ship safely back into the harbour,
  • which implies to clarify and allocate deliverable-related buckets,
• the specs of each development vector and publish finally alike our query builder, which is i.e. a separate task from the above discussion, and
• our understanding of what is to be built, in so the mere implementation of visualisations of filter queries in a map viewer does not impose unneccessary complexity within the grander context.

[species]

What would be the advantage of building filters both on the client and the server?

Saving bandwidth. Alle the POIs are already present in the client's browser cache! There is no need to transfer them again from our API when applying a filter. You don't want to wait until data arrives when you click a filter. This would really badly affects user experience.

There may be a small overhead on this, because you may need to load all the points, but on the other hand servers are optimized to process and you also allow that users with slower computers

• That argument doesn't count when a user is applying a filter on an already loaded dataset in the browser. It has to load the initial dataset anyway, displaying less is no more work.
• Bandwidth is more scarce than computation power, especially when speaking about customers which are low on resources.

The web-browsers are strong enough to filter through at least 50.000 points easily, look at the example of PruneCluster. It is much more load on the central database to filter e.g. 10 points out of 10 million than to do it on a subset on the client. And the more computational load we can take off our database, the less server resources we need (on ecobytes infrastructure!).

---

Back to topic:

@keikreutler If the problem is transferring the structure of the taxonomy.json file (as it is exported from a wikibase SPARQL endpoint) to a more hierarchical structure you could use easier, I can write you a small library if you wish.

[josefkreitmayer]

We just identified 2 discussions here:

• aspect of loading into the client and setting the filters there or just querying from the server
• aspect of the structure of the filters/taxonomy/format

[josefkreitmayer]

@keikreutler today we discussed the issue with yet not a clear result how to resolve.

It would be great / required to get the input of @keikreutler and @almereyda to see how that interacts with the approach of @species and the input we got from @gandhiano today (in the sitin pad at the very bottom: https://text.allmende.io/p/transformap-sitins)

Do you have time for a mumble-meeting today/tomorrow?

It would be especially good to get an impression, what @keikreutler sees as relevant in order to make an easy refacturing of the map with another filterset possible, and what else than the taxonomy.json would be suitable or needs transformation from the taxonomy.json into another format in order to be easily integrated.

The approach, that @species would have originally chosen would be relatively close to the filter-system of the demo-maps: view-source:http://demo.transformap.co/filters.js, and it would be good to get an overall impression, what approach @keikreutler would like to go towards, in order to allign best possible.

[keikreutler]

I'll be on and off available on pidgin for most of the next 5 hours.

I think it's okay to load all the POI initially on client side (with lazyloaded media), but in terms of adding markers to various map layers to be filtered, the json taxonomy does not translate very cleanly to identifying which POI belongs to various categories. I worry that I'm hardcoding in JS arbritary string IDs to find to which category each POI belongs. This does not seem an ideal set up to create an easily reusable filter system with agnostic key value pairs.

Does that make sense?

[species]

@keikreutler in what format would you prefer the json taxonomy to be? If you can give an example, I would be happy to write a small js library to convert the current taxonomy.json to a format that is more easy for your menu implementation to parse.

[keikreutler]

I don't totally understand the visualisation of the taxonomy schema you shared and the relation between category, subcategory and type of initiative tag, and their hierarchy of relations. I also don't understand the relation between Subcategory 1 and 2 and subcategory Q22. So it is difficult for me to write an example, but if you take a look at the code I've written so far in map.js, perhaps you will see the difficulty I tried to outline above?

It would be ideal to have endpoints for the filters which returned related POIs, not necessarily to load them on call via the filter UI but to be able to assign them to different map layers.

as far as I can think about it, an endpoint with something like /api/ssedas-filters with a list of the filters organised hierarchically category > subcategories > types of initiatives. Each containing a URI with something like /api/ssedas-filters?=[category]?=[subcategory]?=[type_of_initiative] to provide geojson collections and add them to their appropriate values.

the question is how many POI have overlap between different categories, subcategories and type of initiative tags, which is what I don't understand from your diagram. Make sense?

[keikreutler]

I don't know if this is the best approach at this point, so would appreciate advice, as this feels fairly out of scope for me.

[species]

I'll try to explain...

• There is a 3-step hierarchical relation in the menu:
  • The first hierarchy are the categories (subclass_of Q1234#SSEDAS_TAX_UUID)
  • In the second step are subcategories (subclass_of one of the categories)
  • The third step are the different types of initiatives, they may be either a subclass_of a subcategory, or (if there are no subcategories for this category) or a subclass_of a category

So we have two different layouts, either if a category has subcategories (left) or not:

I've done a very crude Gimp mockup of how this could look in the UI,

---

• You can ignore Q22, this is only used to describe that this entry is of type category.

---

It would be ideal to have endpoints for the filters which returned related POIs,

We're sorry, the backend is not ready yet for this functionality :-/

not necessarily to load them on call via the filter UI but to be able to assign them to different map layers.

Do you intend to use different map layers for filtering? This could be many, because there are 106 different types of initiative... As we need clustering anyway (and clustering between layers is not possible), I would suggest using PruneCluster for applying the filters, it has an easy way to disable/enable single points.

---

as far as I can think about it, an endpoint with something like /api/ssedas-filters with a list of the filters organised hierarchically category > subcategories > types of initiatives

This is what I had in mind anyway, but we'll need some time - will not be ready before end of June, I fear.

the question is how many POI have overlap between different categories, subcategories and type of initiative tags, which is what I don't understand from your diagram. Make sense?

The only information which is set on the POIs as an attribute is the type_of_initiative. They have no category/subcategory explicitly set, it derives from the position of their type of initiative in the taxonomy "tree". Does that makes sense?

What's to consider in the future that they can have more than one type_of_initiative set (;-separated). If that is a problem now, just use the first value.

---

I don't know if this is the best approach at this point, so would appreciate advice, as this feels fairly out of scope for me.

I also feel that you (wo)manpower is best used in designing, not in implementing heavy JavaScript stuff.

Could you put your focus on getting the menu ready?

As the server-side filters take some time to implement, I can add the client-side filter function myself if you wish.

[josefkreitmayer]

@species thank you for the visualization of https://tree.taiga.io/project/transformap/task/305 and thank you as well for the prompt answering to the questions provided by @keikreutler.

@keikreutler could you probably provide a short note, what you see as good next steps, given the information contributed by @species.

That would be especially helpful given the time difference. Here it is already 23:30. Then we could pick up from there tomorrow morning. thx.

[keikreutler]

Thanks @species.

I understand the UI you're aiming for; thanks for the additional mockup.
The filter menu mockup clarifies the exception cases for the POI.

I will try to use PruneClusters for the filters, though if you could add
the client side filter functions, it would be great. I can focus on the
design.

I suppose this is a larger, annoying and ultimately unuseful discussion at
this stage, but I'm not sure what added benefit having so many categories
gives the user. It may be more useful to have a filter search function.

On Thu, Jun 2, 2016 at 5:33 PM, josefkreitmayer notifications@github.com
wrote:

@species https://github.com/species thank you for the visualization of
https://tree.taiga.io/project/transformap/task/305 and thank you as well
for the prompt answering to the questions provided by @keikreutler
https://github.com/keikreutler.

@keikreutler https://github.com/keikreutler could you probably provide
a short note, what you see as a good next step, given the information
contributed by @species https://github.com/species.

That would be especially helpful given the time difference. Here it is
already 23:30. Then we could pick up from there tomorrow morning. thx.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#23 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AGNJTs9SDmQ7tHqs3TdEoDSGCTVoG_0aks5qH0whgaJpZM4IqEj7
.

[josefkreitmayer]

I suppose this is a larger, annoying and ultimately unuseful discussion at this stage,

I share that assumption ; )

In order not to lose track of the current development conversation, but enable a space to think about the search functionality, you can find another issue on the deployment of a search function here as possible enhancement: issue 28

The feedback we get so far from various sides on the promise to be able to present that much detail is very good.

[species]

As a first step for the library to convert the flat taxonomy.json structure to a tree-like better suited for the menus, I've manually written an example file, see here.

I will followup with a script to generate the whole content as tree-structure from the exported flat structure until tomorrow.

[josefkreitmayer]

@keikreutler can you revise, and comment the input from michael, so you can see he is on the right track for you and our agnostic criteria.
Thank you.
Michael will be off today in about 1 hour.

[matt-wallis]

I have a question about the conversion of the flat taxonomy into a tree structure for menus. Apologies if this has already been sorted out - I have not been following this carefully.
The question: Will the tree structure provide different ways to navigate to the same thing. For example, could there be {Food, Fair Trade} and also {Fair Trade, Food}?

[species]

@matt-wallis The data structure of the "flat" export would permit this type of relations, but we're not using it right now.
As we're pressed for time at the moment, I'll write the 'conversion library' with support for memberships in a single category only. But everything will be open source, so anyone can improve it later :-)

[josefkreitmayer]

@matt-wallis that is a very good question, @species and me were discussing beforehand, as I very much apprechiate that functionality, and it would be possible from the side of the filters. We did not yet adress it on the side of the user interace:

@keikreutler what do you think? Is the following well doable?

For the web-version:

It would be required to have

• check-boxes/buttons to check/uncheck the types of initiatives to filter for.
• mark all & unmark all check-boxes or buttons within each menu of the types_of_initiative
• mark all & unmark all ckeck-boxes or buttons, above the overall menu, so that types_of_initiatives form several categories/sub-categories can be solicitated easily, once some where combined, and another filter is wanted.

For the mobile Version:

• As the complexity to handle on the mobile is very low, we want to produce very low complexity on the mobile web-application. Therefor we will just display the menu until the 2nd level of the sub-categories and leave out the types_of_intiatives to filter for. Therefor, and as well for the complexity of the multi-filter-selection itself, it will not be available on mobile.

best
Josef

[species]

@josefkreitmayer I think you have misunderstood @matt-wallis questions. He was asking if there is more than one way to get to an item present in more than one category.

Are you thinking of applying more than one filter at the same time? I think we should postpone this feature for now.

[josefkreitmayer]

@matt-wallis

• apologies, got your question wrong, but brought up a topic, that is also important to consider
• just had a call with Michael. As we currently do not require it, we won´t take a lot of time for that feature now, but might briefly talk about possible outcomes, if someone tries that with the infrastructure stack (visual map viewer + wikibase filter-structure). @matt-wallis could you open a separate issue for that and label it as "enhancement" and "map viewer"?

Thank you. We can then take it out from this thread in order to keep it short and concise.

[keikreutler]

@species this json structure is fantastic, thank you!

@josefkreitmayer okay, I've added your criteria of the check-boxes/ buttons to the taiga task https://tree.taiga.io/project/transformap/task/305

[species]

@keikreutler I've wrote the convert-library, see here. I've also checked in the generated file, if that's easier at the moment.

[matt-wallis]

@josefkreitmayer you didn't misunderstand my question, you took it to the next step which is to recognise that hierarchical menu systems may not be sufficient for choosing between a set of tags which do not have a natural ordering! However, I understand that you are under time pressures - I have raised a new issue: #30.

[keikreutler]

How are the type of initiatives (for the third tier of the menu) identified?

@species wrote earlier:

There is a 3-step hierarchical relation in the menu:

• The first hierarchy are the categories (subclass_of Q1234#SSEDAS_TAX_UUID)
• In the second step are subcategories (subclass_of one of the categories)
• The third step are the different types of initiatives, they may be either a subclass_of a subcategory, or (if there are no subcategories for this category) or a subclass_of a category

I'm confused about whether to look for the subclass_of property, and if in the case of types of initiatives which don't belong to subcategories but rather categories, in what way they're differientiated within the JSON structure from subcategories. Should I parse the instance_of property?

Perhaps the easiest way for me to see this, would be to know one existing example of a category > subcategory > type of initiative and one example of a category > type of initiative and trace this relation back within the JSON structure.

[species]

@keikreutler The type of an entry is identfied by its "instance of" attribute.

One example of a cat-subcat-toi relation would be "community garden"(toi) ->"Grow it yourself & together"(subcat) -> "Food and Agriculture" (cat).

An example of toi->cat would be "Microfinance"->"Finance"(cat).

[josefkreitmayer]

example for category - Type of Initiative - Relation without Sub-Category:
Category: Finance
Type of Initiative: Microfinance

---

{
"item": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q10008"
},
"itemLabel": {
"xml:lang": "en",
"type": "literal",
"value": "Finance"
},
"instance_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q22#taxonomy_category"
},
"subclass_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q1234"
}
},

{
"item": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q19002"
},
"itemLabel": {
"xml:lang": "en",
"type": "literal",
"value": "Microfinance "
},
"instance_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q13742#TypeOfInitiative"
},
"subclass_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q10008"
},
"type_of_initiative_tag": {
"type": "literal",
"value": "microfinance"
}
}

[josefkreitmayer]

example of a category - subcategory - type of initiative relation:
Category: Food & Agriculture
Subcategory: Buy Local
Type of Initiative: Local Farmers Market

---

{
"item": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q10001"
},
"itemLabel": {
"xml:lang": "en",
"type": "literal",
"value": "Food & Agriculture"
},
"instance_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q22#taxonomy_category"
},
"subclass_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q1234"
}
},

{
"item": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q30002"
},
"itemLabel": {
"xml:lang": "en",
"type": "literal",
"value": "Buy local"
},
"instance_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q22#taxonomy_category"
},
"subclass_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q10001"
}
},

{
"item": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q12011"
},
"itemLabel": {
"xml:lang": "en",
"type": "literal",
"value": "Local Farmers Market"
},
"instance_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q13742#TypeOfInitiative"
},
"subclass_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q30002"
},
"type_of_initiative_tag": {
"type": "literal",
"value": "local_farmersmarket"
}
}

[keikreutler]

When you sent me a Skype message yesterday, I let you know I had already
figured it out. Thanks though!

On Thu, Jul 7, 2016 at 12:56 PM, josefkreitmayer notifications@github.com
wrote:

example of a category - subcategory - type of initiative relation:

{
"item": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q10001"
},
"itemLabel": {
"xml:lang": "en",
"type": "literal",
"value": "Food & Agriculture"
},
"instance_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q22#taxonomy_category"
},
"subclass_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q1234"
}
},

{
"item": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q30002"
},
"itemLabel": {
"xml:lang": "en",
"type": "literal",
"value": "Buy local"
},
"instance_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q22#taxonomy_category"
},
"subclass_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q10001"
}

},

{
"item": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q12011"
},
"itemLabel": {
"xml:lang": "en",
"type": "literal",
"value": "Local Farmers Market"
},
"instance_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q13742#TypeOfInitiative"
},
"subclass_of": {
"type": "uri",
"value": "https://base.transformap.co/entity/Q30002"
},
"type_of_initiative_tag": {
"type": "literal",
"value": "local_farmersmarket"
}
}

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#23 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AGNJTmZeZeWpmIWt1Km-OKbRAiFQ7BKTks5qTNtngaJpZM4IqEj7
.

[josefkreitmayer]

implementation and documentation moved here: https://github.com/TransforMap/transformap-viewer