Sorry I don't think I understand your exact scenario. Could you elaborate a bit? Are you using Ontologies or some instance asset collection such as Data Graphs/Taxonomies? That impacts which properties are editable. And on your first question, what do you mean they are not displayed?
Some concrete example snippets would help.
Thanks,
Holger
--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/8270ef30-e3ed-4192-b09c-ef1a154cdee2n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/e8ff942a-46a7-5322-d9b3-4d1a4e07b7ce%40topquadrant.com.
Thanks,
Nevertheless, I have just three kinds of asset collections in my version :
- Taxonomies, Ontologies and Crosswalks.
For the second option I haven't this option also in my topBraid.
But why we can not edit instances by default please ?
There are various reasons for our recommendation that
- Ontologies should only contain classes, properties and shapes
- Instances should go into all other graphs
One technical reason is that changes to ontologies may cause internal overhead, e.g. rebuilding of GraphQL schema and other optimized data structures. In a typical project, changes to ontologies are much less frequent than changes to instances, so it's usually a good assumption that the ontology will be stable so that these other data structures can be kept stable too.
But also from a design perspective it is quite natural to keep ontologies/schemas and instances separate, because schemas are typically reused across multiple instance graphs. Exceptions are instances that represent enumerated instances, e.g. the colors of traffic lights, or the 12 months of a calendar.
Mixing schema and instances may be convenient for quick
prototyping but keeping them separate is in our experience a good
long term investment.
Holger
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/a898b3e8-bfb4-459f-aa5f-18c67330f32an%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/5fb1aba6-8bdf-5e2d-1527-800a1cb9fbfb%40topquadrant.com.
A related perspective
following a test-driven design philosophy, ontology development requires instance data for testing, and best practices for documentation require illustrative examples.
Thus while editing example instances in a separate graph we want to be able to attach these to the Classes. Which means some editing of statements about the classes and properties, and navigation from classes and properties to related examples _in the data graph_ is desirable - but AFAIK not supported.
(maybe this can best be done with inverse paths from the instances to the classes - but we want to be able to navigate the classes to find the instances.)
Yet I wonder why would you ever want test data in production files? It is common practice for test files and sample data to be in separate files.
Holger
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CACfF9LzR-2edu5_F9PYtsd63j%2Bc14WgqU-hy%2BN%3Di12fFgU%3DQQQ%40mail.gmail.com.