I see updating the namespace in Designer as time-consuming (either I rebuild the model to change the default namespace or I go into each resource and attribute and change).
We have captured this as an area for improvement to allow bulk updates. Thank you for your feedback!
Changing the namespace in Studio seems the less time-consuming path. Do you foresee any mishaps between the updated files in Studio and the settings in Designer? For example, if I change the namespace in the Models and Virtual Graph hub files plus I update the namespace setting in Designer, will Designer maintain that update (so that in between Designer sessions the namespace setting doesn't revert back)?
I would recommend that if you do not plan to update the model and mappings through your original Designer project going forward, you use a new project. Where you first import the model you have in Studio. Designer projects are not live reflections of the model and mappings on your endpoint so your original project will have the incorrect IRIs. If you think you'll want to modify your mappings through Designer, I would recommend updating your model in Studio (as your stated preference), creating a new Designer project (updating the project namespaces) and importing the updated model, and then remapping your resources. This would allow you to modify your mappings through Designer and re-publish. Otherwise, you will need to modify your mappings through Studio.
Once a Designer namespace for a project is updated, it will keep the update between settings. But again, Designer is not a live reflection of your data model and mappings on your endpoint, so your updates in Studio will not be reflected in your original Designer project.
Also, a question about querying a model versus the underlying virtual graph. Below are two queries where in one I point to the virtual graph and the other I point to the model. The former results in data (1), where the latter doesn't (2). The difference below is the
From command. Is there something I am missing about the query?
Knowledge graphs are made of composable elements. These elements at the highest level for a database are segmented into graphs. The FROM clause specifies which graphs are within your queries scope. Studio allows you to specify the scope directly in your SPARQL query or through the named graph drop down filter (layered icon next to databases, shown below).
By specifying the model graph in (2), you are limiting the scope of your query to only your model graph. Your model graph only contains your model definition, not also your mapped data.
The first query where you specify the virtual graph results in data since you have a graph with data within your query's scope. The mapping contains implicit model definitions since your mapping has to specify that instances are a specific class type and that properties such as
Explorer handles the above case by always including a model scope and a graph scope (can also think about graph scopes as data scopes). For instance, in the image below, I have all virtual graphs in scope and my model
Hope this helps!