Open DiegoPino opened 5 years ago
@DiegoPino I start from the last question: I agree to use unique prefix per KeyName provider because I think this can help and make code simpler. I.e. 'ap' prefix is reserved for Archipelago internals. I know people are free to use own vocabulary but we need some fixed point. Regarding 2. I fully agree with that. SBF Vocabulary is dynamic and could grow a lot so exposing only useful keys (leafs with value) will be really appreciated by users. Regarding 3. If I understood, aggregator is something as an harvester from SBF-JSON to collect same type keys as you explain. The need is only to index them or putting them into SBF-JSON? Regarding 1. I think that it would be automatic, almost at the first stage, for internal prefix as 'ap'. Allowing users to set own key for references implicates users very skilled so I'd left that for next step. Finally, sorry for my notes not so deep into code as you, I hope this can help.
Hi @giancarlobi thanks as always!
entities:allmynodes
Hope this makes sense.You analysis is top notch! "strabiliante!" and your suggestions excellent. This all feels disconnected from your strawberry runners work, but it is not. I already have a great idea on how to process data in better ways (JSON) using better exposed properties.
Big hug!
This all feels disconnected from your strawberry runners work, but it is not. I already have a great idea on how to process data in better ways (JSON) using better exposed properties.
I have no doubt that this was related to runners, I fully trust your "fantastiche" ideas, thanks again!
Some advances here! Entity Reference indexing coming from any JSON key via JMESPATH
https://github.com/esmero/strawberryfield/commit/a3a95a02be866de918a7cb08926ecdc8d544261b More soon
What is needed?
As we move forward and our SBF JSON becomes more rich, we should start thinking and coding new types of JSON Key Provider Plugin implementations. This is related to #33 but goes beyond.
The ones i want and need:
The implementation is quite simple:
ContentEntityBase provides already a method:
\Drupal\Core\Entity\ContentEntityBase::referencedEntities
Which goes field by field checking for EntityReference Properties
So what we need is a JSON key provider that exposes a set (one or more) JSON property values (node ids for example ) as \EntityReference class properties.
We have at least two ways of providing the JSON keys as arguments:
First, automatic, by using the new "ap:entitymapping": [] key we preprocess (or should because webform maintainer dismissed my pull request for that...gosh)
Or by allowing people simply to type the keys (hopefully in this case a full JSON Path?) that contain entity references. Example are ismemberof, scene, etc. With that Solr will allow us to co-index those referenced entities values, like their labels, etc.
Here is how i envision that:
Only keys that should be exposed are the leafs of a branch.
So if we have :
What we want to expose is as:document.*.checksum for example, which is really just the value of what is inside .checksum in that hierarchy. That seems also straightforward to do, logic would be
3.- I want an aggregator KeyName provider, one that takes a few different keys from all over the JSON and unites them in a single property to JSON. The UI for that could be a little bit more cumbersome, and thinking loud, it could be even working on Properties we are already exposing via the other KeyName Providers? Or do you think we should keep this one at the same level? Same level means less dependencies.. that is good. After process, means a different level, means the keys can be selected, instead of typed by the user. The need for this is: get all referenced external URLS around the JSON and put then inside a single Solr field named URIS.
Logic here is simple
This plugin takes a bunch of keys, accumulates the values from all of them and then exposes all under a single, different Key name.
Questions:
Do we want to name, prefix, fields coming from a given KeyName provider differently so people can deduce who exposed them? Ideas?
@giancarlobi @marlo-longley