Diffusion/API/front end

Clare

Are we doing anything wrong? We are struggling to see the error. We are using the standard diffusion ontology for numismatics.

Clare

Any guidance welcome! :-)

Alex

Clare we are now trying to publish the remaining data, but it is now not working

Hi Clare

With the information you're providing, it's difficult to determine the issue. Could you please share your PHP error log? When you're setting up the publication, it's crucial to monitor your PHP error log to identify and resolve any problems. Sometimes could be a permissions, sometimes could be a wrong data, sometimes could be a small RAM allocation to PHP, sometimes could be a ?????

To monitor the PHP error, you can use the tail command with the -f flag and reproduce the error in Dédalo.

tail -f /var/log/php/php_error_log

Note: The path and name may vary depending on your GNU/Linux distribution and implementation.

Best

Clare

Hi Alex - many thanks for the suggestion of looking at the php. We have used some fields which don't seem to be in the standard diffusion ontology and are getting errors there - I guess we then need to add them to the ontology in the UI to get everything to work? The fields are object (object1)
technique (technique1)
numisdata300
rsc332
numisdata41
numisdata38
material1
numisdata6
I did do some reading on this but I confess I remain a bit bewildered (and scared of breaking things!) Is there any guidance on how to add these, if this is indeed the issue? (I thought maybe things not in the ontology would just not be published, but anyhow).

Alex

Clare

Hi Clare,

I'm a bit confused about your comment regarding the fields you mentioned.

object1 -> thesaurus section for object names as coin or anphorae
technique1 -> thesaurus section for techniques as Struck
material1 -> thesaurus section for materials as gold or silver
numisdata6 -> mints section
rsc332 -> Bibliographic resource section
numisdata41 -> Legend section
numisdata38 -> Design section
numisdata300 -> the thesaurus for catalog.

They are ready to be processed by the default definition of numisdata. I'll show you some of them.

Could you please explain what Dédalo is referring to in the PHP error log regarding these fields?

Best

Clare

We also have (a lot) of this in the logs, but the docs don't say what it needs to be set to, and comment in the file says "// dedalo_entity_id . (From Dédalo private list. You need to be register before but it's not mandatory fill this)" Note that config file default is 0 (Zero) for DEDALO_ENTITY_ID. Review your config
[seq]: diffusion_sql:update_record > diffusion_sql:build_table_columns_data > diffusion_sql:build_data_field > diffusion_sql:generate_rdf > diffusion_rdf:update_record > diffusion_rdf:build_rdf_data > diffusion_rdf:build_rdf_node > diffusion_rdf:build_rdf_node > diffusion_rdf:resolve_base_u>
[03-Mar-2026 09:21:04 Europe/London] ^[[43mDEBUG_LOG [ERROR]
diffusion_rdf::resolve_base_uri Error . this->entity_locator is empty
this->entity_locator: null
constant config DEDALO_ENTITY_ID: 0
base_uri_entity: {
"title": "nomisma",
"section_tipo": "dd1010",
"component_tipo": "dd1014"
}
so we don't think this is the issue? Thanks!

PaCo

Hi Clare

DEDALO_ENTITY_ID is not required in most cases, but it is necessary for RDF export to create the entity publication service locator to use for get the URL base.

The official list is supported by the Dédalo community in the master repository.
E.g. for the MIB installation, DEDALO_ENTITY_ID = 5 (MIB entity id).

Maybe you need to request your own DEDALO_ENTITY_ID (estable URL is needed).

For now, if it is not essential, you can disable RDF from the publication.

I hope this helps.
Let us know how it went.

Best

Clare

PaCo Thanks for the suggestion. We are just using a temporary url at the moment so we don't think we need this (it works as any should?) Let me know if this is not the case. Otherwise we will continue to try and figure out where our error is coming from. :-)

Alex

Hi Clare.

The DEDALO_ENTITY_ID is used to match it with the nomisma ID. When you want to share data in OCRE or any other aggregated portal that uses Nomisma, you need to have a Nomisma ID, which is the URI representing your identification in the Nomisma ontology.

For example, Moneda Ibérica has this Nomisma ID:
https://nomisma.org/id/mib

This ID must be included in the RDF of your data, so the DEDALO_ENTITY_ID indicates where this Nomisma's unique ID resides within the Dédalo ontology, because you can share your data in others standards that use others ID, the DEDALO_ENTITY_ID is the unique identifier for all of them.

If you don't want to share your data in RDF Nomisma format, you can use any existing ID as @PaCo suggests. However, if you want to share your data with RDF, you'll need both the Nomisma ID (ask any Nomisma members) and your DEDALO_ENTITY_ID.

I hope is clear.

Best

Clare

Thanks that makes sense, thanks! Ok we think then the issue may be we have used fields that are not in the standard numisdata ontology UI - we will try and put these in and try again. :-)

Graham

Hello Alex,

Here is the output from the diffusion:
{ "pid": 180549, "pfile": "process_-1_2026-03-04_17-36-27_219586143820478", "is_running": false, "data": { "result": true, "msg": [ "EXCEPTION caught [export_list]: $uri is null and EasyRdf\\Graph object has no URI either.", "Warning. Request done with some errors: 1" ], "errors": [ "$uri is null and EasyRdf\\Graph object has no URI either." ], "diffusion_data": [], "memory": "64 MB", "last_update_record_response": { "result": true, "msg": [ "Record updated section_id: 2. Number of references: 11 in levels: 2" ], "errors": [], "class": "diffusion_mysql" }, "time": "2 sec" }, "time": "2026-03-04 17:36:29", "total_time": "2 sec", "update_rate": 1000, "errors": [] }

Too much mess in the .log file, to include here, will e-mail separately.

Regards, Graham

Alex

Graham "EXCEPTION caught [export_list]: $uri is null and EasyRdf\Graph object has no URI either.",
"Warning. Request done with some errors: 1"

Okay, I understand. The issue lies in the RDF process. Some resources lack an URI or have an invalid URI, making it impossible to create the graph.

In RDF is mandatory that every resource has its own URI. If your data doesn't define a nomisma URI for each resource, the process will fail. And it stop all diffusion process. Nothing is wrong for the MariaDB process, but the RDF creation stop all and nothing is saved into the SQL.

DEDALO_ENTITY_ID provides a safe way to solve it, because it defines a common base uri for all your data.

Okay, here's a question: would you like your Dédalo to create the RDF graph?

Since I suppose you'd like that, we've opened the DEDALO_ENTITY_ID for you as a provisional config. It currently has a fake URI that can be replaced with the "correct" one once you have your nomisma ID and final URI.

Your DEDALO_ENTITY_ID is 16

Add it into your configuration, locate it into /dedalo/config/config.php

define('DEDALO_ENTITY_ID', 16);

And update your ontology to obtain the configuration, of your DEDALO_ENTITY_ID

https://dedalo.dev/docs/management/updates/updating_ontology/

I hope that it resolves the RDF situation... 😉

Best

Alex

Hello again

Perhaps we should modify the default configuration for numismatics to publish the nomisma RDF using a Dédalo URI, such as https://dedalo.dev, until the project has its own stable URI. (This change should remove the annoying RDF configuration)
But, if the project don't make the URI change and send your data to the RDF aggregators, it could be an issue. I'm not sure if it's better to be stricter or permissive about the URI configuration.... What do you think?

Best