Handling keywords in a better way by adding paper-tags and updating database structure

[dave-mills]

Want to replace big paper-tabs part of the resource editor with paper-tags: https://www.webcomponents.org/element/PolymerEl/paper-tags/

Aiming for using a for keyword add / remove, and a for adding new keywords right there in the editor. This should make it a quicker process for Savitri, Ric, Carlos et al to add new keywords as they go through and edit resources.

As a consequence of this, I think keywords should be database objects like { id: "9e8rwhotujnls", label: "data-flow"} instead of the current array-like structure. (Partly because paper-tags requires an id / label style structure, and partly because it lets us add extra properties to the keywords later on).

[dave-mills]

Thinking about it, (and back to our whiteboard-table discussion about database structure a while back), I guess if we make keywords objects, we should throw them into the same bucket, and sort via a 'type' property? So:

{ id: "9e8rwhotujnls", label: "data-flow", type: "topic"}.

@chrismclarke what do you think?

[chrismclarke]

Yes that would definitely be nice. As a bonus we could also include ‘;’ or ‘,’ to submit tag.

[chrismclarke]

This might be making things a bit complex in the early stages. I’m still thinking of keywords in terms of academic papers, so really just simple terms to help find a resource, relating to the content of the resource and not type.

In this case we have the following:

Keywords – general terms relating to the content, to help identify and search (e.g. climate, distributions, modelling…) Types – terms relating to the structure of the resource (e.g. research paper, short course, tutorial, checklist, website…) Collections – specific groupings of resources (e.g. R coding, qualitative analysis, …)

[dave-mills]

Sorry, I think I'm getting the words tags and keywords mixed up, as usual. I meant throwing all of them into a single bucket, so we're no longer handling Types, Keywords, Collections, Topics as separate things, but just handling "tags", where some are: {type = "keyword"}, some {type="type"} etc.

[chrismclarke]

Ah, I get it. Sure why not.

[dave-mills]

I did it! I frickinn did it and made it work!

Ahem.

Tags now working again in ssd-resources-full and ssd-resources-editor. Database updated to more closely resemble structures that firebase / json docs recommend for many-many relationships:

• Tags are now stored as objects, and those objects are referenced in the resource objects.
• Resources still have resource.keywords, resource.collectionsetc, as I figured we would always be filtering into these separate lists anyway when looking at resources. (Could change later if I'm wrong)
• Using paper-tags within a custom ssd-tag element to display the tags in the ssd-resource-full element.
  • ssd-tag receives a tag id, then uses a firebase-document to retrieve the object with that id. (This is how it gets the label for that tag).
• Using paper-tags-dropdown for the ssd-resource-editor. This already does a nice job at linking the [[persistedTags]] array and the set of ids in resources.##tag##. Not totally sure how, but it seems to work.

(reference: structuring firebase data )