Adding additional meta-data to assets in Watson Knowledge Catalog - watson-knowledge-catalog

Currently, my understanding is that the Watson Knowledge Catalog only has options to add predefined meta-data for data assets, Is there any way to add additional meta-data via UI or APIs. Say If I add the additional meta-data via API, will it be searchable & exposed through the UI?

You can add additional metadata to any assets or create custom asset types. You do this via PUT /v2/asset_types/{type_name}.
Within the asset type, you can set whether any additional attributes or metadata are searchable or not. Once you do, then any new assets of that asset type can be populated with those additional attributes and you can instantiate searches off that metadata.
The new asset type will appear in the UI; however the additional metadata will not appear. This is an enhancement we are hoping to achieve in a foreseeable future.

Related

Modification to published magnolia components

Let suppose that in Magnolia's Page application you have few pages with instances of component "A" which have property dialog. These pages are published to Public server.
later you decide to change structure of this properties (add fields or for example change image field to array of images)
to do so you would modify component's dialog yaml file (add/modify fields) and component's template ftl file to render these changes
Question: - will this destroy previously created pages with instances of component "A"? i.e. if you need to modify component's properties it's better to create new component instead of modify existing?
It's fine to modify existing component, as long as you take care of the fact that existing instances will not have any values for newly added properties/fields. So in template you need to expect that you might get empty values and provide good defaults to cover that case. So technically, you can modify the component just fine.
Whether it is better to create new component or modify existing one depends more on the business needs. Is it desired pages to see new component look & get new fields in pages that already use the component or are those changes relevant just for new pages in which component will be used?
Another consideration is the more components you have, the harder it would be for editor to pick the right one from the ever growing list. However the more functionality you cram into single component, the more complex and difficult to test it would become and harder it would be to replace it with something else in the future.

how does common metadata fields from content alfresco work?

I created with the help of model manager a custom type for my folders and all I want is to have some sort of popup window to fill all the properties and then spread to all the files inside that folder, Is there any relation with the rules of folders and common metadata fields from content? Any help would be apreciated thx
If you configured a form along with your custom model, you should already have a way to edit the custom metadata on your folders.
If you also want that same metadata on your content, then hopefully you implemented your custom metadata on an aspect. The aspect can be applied to folder instances as well as content instances.
Once you have an aspect applied to the folder and content instances, it sounds like the next thing you want to do is copy metadata values from the folder to the content. There is nothing out-of-the-box that will do this for you. You can do this with a rule.
I suggest reading the documentation on the Alfresco server-side JavaScript API and also installing the Alfresco JavaScript Console add-on. You can create a server-side JavaScript file that will reside in Data Dictionary/Scripts. Then you can set up a rule on your folder to invoke that JavaScript to copy metadata from the folder to the documents when the documents are created.
Keep in mind that if the metadata on the folder changes you will have write a rule to deal with that if you want to copy the updated values to the content instances in the folder. This could get very expensive if the folder grows in size.

Location for Symfony bundle templates

The directory structure for bundles specifies that views should be stored in <your-bundle>/Resources/views. But then the best practices for template locations says that, actually, I should store them in app/Resources/views. I can see the conveniences of doing the latter, but I don't understand:
If I am organizing things into bundles, aren't I reducing the bundles' portability by "de-bundling" the views?
The examples show that index.html.twig is easier to write than AcmeDemoBundle::index.html.twig, but what if I also have FooBundle::index.html.twig? I still need a way to specify which index.html.twig I want, right?
The documentation is correct. Store reusable bundle's templates in <your-bundle>/Resources/views and your project's templates in app/Resources/views. There is no conflict.
If you decide to create a bundle make sure it can be reused (that's the main purpose of the bundle). Otherwise keep using your AppBundle. AppBundle will not have two /index.html.twig's.

Create a new custom field option in redux wordpress framework

I want to create new field in redux wordpress framework using Custom fields, but I can't find any help or example using this.
i want to create a field with a switch and text field both.
Any suggestions is most appreciated.
Lead dev of Redux here.
If you want to make a new field, then you should build an extension. We've setup two repos that will help you get started.
First:
https://github.com/ReduxFramework/extension-boilerplate
This is an extension boilerplate. It will help you see how to do this.
Second, is the extension loader:
https://github.com/ReduxFramework/redux-extensions-loader
This will load the extension. You can also use it to overload any existing Redux fields.
Be VERY careful to load your Redux options in this order:
Extension Loader
Redux Options Config File
Otherwise Redux will be initialized before you run the extension hooks to overload/add new types. From there you just call your custom field type like you would any other field.
Good luck!
In order to update the answer, it's important to note that this page refers to the legacy method to load extensions.
The current method to load extensions is by adding the next line into redux config file (I guess is OK to add it at the end of the file).
Redux::setExtensions( 'OPT_NAME', 'FULL PATH' );
...from the docs:
Be sure to replace OPT_NAME with your opt_name and FULL PATH with the full path to your extension(s) location.

Exporting Plone Archetypes data in JSON

I'd like to export Plone folder consisting of custom Archetypes content items in JSON.
What addons and tools there exist for this? Preferably one which automatically inspects schema and creates JSON structure based on it.
I have successfully used collective.jsonmigrator / collective.blueprint.jsonmigrator for this purpose. It's meant to work with transmogrifier. I was even able to export json from a prehistoric Plone and import it into a Dexterity content type in Plone 4.1.
This kind of extreme migration is never easy, and if there's any customization at all, you'll probably need to do some source tuneups to make the pipeline work.

Resources