Diffusion of authority

Clare

Hi All - apologies, but I am struggling to get the diffusion working for authority (numisdata249). I added the entry to the local diffusion ontology, but perhaps I have made an error with the set up or directing where the data is to come from. When I followed the data through several tables (here Gratian), I thought the field was rsc1156 but maybe that is wrong, or maybe I have filled out the ontology section wrong! Some screenshots of my attempts

below!! Any advice very welcome. :-)

Alex

This resolution involves multiple steps, and you haven't provided the complete path.

Step by step:

1) Type numisdata3 has a portal Authority numisdata249

And your diffusion node define correctly the relation in the Connected to

The table call to Type and you want to use the data into Authority. All ok.

2) Next step Authority numisdata249 portal call to Authorities group numisdata1374

3) Authorities group numisdata1374 has a portal (as autocomplete) Ruler numisdata1379 that calls to People references rsc1152

4) And People references has the Person rsc1156 that you want to obtain for the column.

The full path:

numisdata3-> numisdata249-> numisdata1374-> numisdata1379-> rsc1152->rsc1156
section->portal->section->portal->section->portal

Therefore, you must define the full path of your target using the components, the portals, and you are defined only the source and the final target.

In v6 the path is nested and complex, in v7 the paths as re-defined to be more clear and easy to understand.

v6:

{
  "process_dato": "diffusion_sql::resolve_value",
  "process_dato_arguments": {
    "output": "merged",
    "component_method": "get_diffusion_resolve_value",
    "custom_arguments": [
      {
        "process_dato_arguments": {
          "component_method": "get_diffusion_value",
          "target_component_tipo": "rsc1156"
        }
      }
    ],
    "split_string_value": " | ",
    "target_component_tipo": "numisdata1379"
  }
}

v7:

{
  "process": {  
    "ddo_map": [
      {
        "tipo": "numisdata249",
        "section_tipo": "self"
      },
      {
        "tipo": "numisdata1379",
        "parent": "numisdata249"
      },
      {
        "id": "a",
        "tipo": "rsc1156",
        "parent": "numisdata1379"
      }
    ]
  }
}

Note: Why does the chain use only portals and not the sections? Well, you must define the section when the path has multiple sections to resolve. For example, a portal that calls People and Entities. However, if the target section is always one section, it's not necessary to define it because the ontology knows what the target sections are. The path is clear and can be resolved.

Note2: you are pointing to a portal, your last item in the chain is not a literal it's a relationship, so, maybe you must go deeper into the relationship and resolve the name rsc85 and surname rsc86

Note 3: I haven't tested the properties, so it might not work directly. They are just examples of how it works. If you test it and they don't work, and you can't find a solution, I'll reproduce this specific resolution. However, it takes time.

I hope is clear.

best

Clare

Hi Alex - many thanks for explaining, it is indeed complex. I did try and follow the full path as you outlined, but I am afraid nothing is diffusing. But perhaps I set the model as wrong in one section, or did something wrong..... screenshots below of my attempt in case you can spot my errors there. :-) If it is too complicated maybe it is something we can look at in September!

Alex

Dear Clare.

Yes, it's complex... but I'm thinking that you are doing it much more complex than it is!!!! 😃 (perhaps I didn't explain clearly myself.)

1.- You must not create multiple ontology diffusion nodes for this resolution.
The rule is: one diffusion ontology node by column resolution (no more, no less).
The diffusion node defines the path to obtain its own data, so the path is inside the diffusion ontology node.

2.- Diffusion is a different ontology definition than working ontology nodes. Why? Because the definitions must be adapted to the scope of the use (SQL, RDF, etc.), and diffusion must be more stable than the work data, because they are the public face. In v7 we are changing the diffusion ontology to be more clear in this because the definition is old (it has more than 20 years and it needs a review).

So, see a similar resolution with the node bibliography_author numisdata1078

Remove the nested nodes (they're unnecessary). Then, try replicating it using your Ruler numisdatauow39. You can copy and paste my v6 property definition into the yellow field labeled v5 Properties. (This is the v1, v2, v3, v4, and v5 definition that will be replaced by new v7.... and v6? this is another historical note. In short, it must be changed in v6, but it was delayed.):

{
  "process_dato": "diffusion_sql::resolve_value",
  "process_dato_arguments": {
    "output": "merged",
    "component_method": "get_diffusion_resolve_value",
    "custom_arguments": [
      {
        "process_dato_arguments": {
          "component_method": "get_diffusion_value",
          "target_component_tipo": "rsc1156"
        }
      }
    ],
    "split_string_value": " | ",
    "target_component_tipo": "numisdata1379"
  }
}

and try... if they don't work... we can review it in September...

Best
Alex