There is room for a new convenience feature here - a wizard that
produces "proxy ontologies" for a collection of (OWL) ontologies that
have been uploaded into the workspace (or would be downloaded from a
given URL). Such a feature would offer the user to select which of these
uploaded graphs to pick, and then would produce one EDG Ontology for
each selected graph, with a label such as XY Shapes. Each of these
graphs would owl:import the graph that it wraps and include the shapes
produced by OWL2SHACL. If the original graph has owl:imports then the
proxy would contain owl:imports to the respective proxy ontologies.
So assuming you have TTL files
A owl:imports B
B owl:imports C
the algorithm would produce
urn:x-evn-master:A owl:imports A, urn:x-evn-master:B
urn:x-evn-master:B owl:imports B, urn:x-evn-master:C
urn:x-evn-master:C owl:imports C
Users can then manually post-process the SHACL axioms where needed and
generally use the SHACL versions instead of the original ones. The
labels, comments, subClassOf triples etc of the original files would
"shine through" from the owl:imports closure, and there is no harm in
keeping owl:Restriction triples or RDFS domain/range statements in the
original files either.
I'll record this idea as a ticket, but wanted to put this out here in
case anyone has further feedback. It doesn't sound like huge development
effort.
Holger
On 24/04/2020 10:34, Rob Atkinson wrote:
I too find it awkward when I am working with immutable OWL
resources from standards but EDG requires the shapes - so end up
doing complex automated loading where I generate a wrapper
ontology to contain created shapes and then update imports in
instance data to include these shapes instead of the original
ontology so EDG works. What I really need to do of course is to
have the shapes file be a profile of the original ontology that
matches the things I care about and not populate the environment
with a lot of irrelevant stuff - which matches the original use
case - only show relevant classes.
Please help me understand the user experience that you'd like to
see here. TopBraid would, if available, basically always request
a SHACL-profiled version of an ontology. Even with the automated
converter some ontologies require manual post-processing of the
SHACL. So are you suggesting
- to have some alias mechanism that automatically substitutes one
owl:import with another owl:import so that a SHACL file gets
preferred over a pure OWL file?
- to run the OWL2SHACL algorithm if an ontology seems to contain
an OWL ontology that is not covered by SHACL? If yes, how would
it recognize that.
I run into similar situations on occasion. Right now I have a
scenario that needs about 15 classes and about 80 properties that
are largely taken from standards like DC and Prov-O. However, if
you import everything that is required to make the graphs complete
you end up with the items of interest being maybe 25% of the union
of the ontologies. IMO a way to address that issue elegantly would
be a far more useful feature than worrying about changing an
import here or there (e.g. can workaround that by adding shapes
import to the OWL and you don’t have to modify any data graphs).
yes - thats exactly the issue
Note that this problem isn’t actually about SHACL or OWL2SHACL. It
also appears in any OWL-driven UI where the user is forced to see
the entire content of the ontologies in the scope of the imports,
even when not of interest.
Seems like a nice way to specify “the things I care about” before
doing the OWL2SHACL might do the trick in EDG. At the moment, to
say what I care about I sometimes delete things from my local copy
of the “immutable” ontologies such the they contain only the
subset of interest.
Shapes give us this opportunity - so the question is how to get shapes
created and into play in the most elegant way possible
After-the-fact you can deactivate shapes and in EDG you can use
Main Class to help some. However, would be nice to be able to
specify “the things I care about” once and have that flow thru
into everywhere appropriate in EDG to limit the UI to only show
that subset of the larger scope.
So for a given ontology there are actually multiple choices for
what you show in the class view:
1) all the classes in the ontology using the current graph with
imports
2) all the classes in current graph
3) only the classes represented by instances in the current graph
4) only the classes represented by instances in the current
graph with imports
5) all the potential classes defined by a shape - a profile of
the closure over owl imports. - allowing you to select classes
not populated and create new instances.
I assume all these cases could be expressed using SPARQL queries.
So you could probably save those queries and re-run them from the
SPARQL Library panel? In 6.4 we are adding the ability to
parameterize those SPARQL queries, so that when you press the
execute button you can fill in the values for any "pre-bound" $
variable.
SPARQL is no problem - but its 'off to the side' in the UX - what we
are talking about is being able to quickly move from comprehensive
OWL+instances to an EDG friendly SHAPE-I-care-about + instances view.
There are a few challenges with using the OWL2SHACL converter (in
either EDG or TBC) - you need to start with:
D = my data
O* = the imported ontology set (with standard transitive closure of
imports)
D imports O*
EDG cannot do much with D at this stage ..
So we need to end up with:
OS* = set of possible shapes derived from O* - where each O in O* has
a corresponding shape graph OS and OS imports O
S = my SHAPEs of interest - selected from OS*
D imports S
D imports O
create T
T imports O, OWL2SHACL
run transformations
Save T
Remove imports from T
T imports O
D imports T
(this is actually more complex if you want to allow it to be guided by
the data in D - unclear if EDG restrictions on instances and classes
get in the way here)
and finally D is EDG ready!
But we still have a zillion shapes derived from O* making it
unfriendly ;-( .... T != S
so if EDG supported T imports D - and only deriving shapes relevant to
the data it would help - but only if you had data in advance.
Selecting specific classes would be fine - but for this to be workable
it needs to allow you to choose a superclass and all sub-classes get
converted.
- one possibility is to selectively import OS from OS* - i.e. the
imports of shapes needs not to be transitive - but this may not be
possible without yet another dance to duplicated and remove imports -
so it may just be necessary to create declarations for _all_ shapes in
OS* and declare them deactivated. This feels kinda horrible - and I'm
not sure its what you want anyway - what we really want is to have S,
but inherited any constraints from OS* without promoting these to
being first classes members of S - my shape of interest. Maybe I'm
missing a mechanism here.
If EDG only uses the direct imported shapes graph then that would keep
all the imported details hidden - but it would stop you using modular
design of your own shapes - a Bad Thing
But we also need to make OSx in OS* - as separate graphs because O*
must be read-only!
At the moment we need to do a complicated dance:
D imports O
create T
T imports D, OWL2SHACL
run transformations
Save T
Remove imports from T
T imports O
D imports T
and finally D is EDG ready!
so really we want D imports S*
Sx in S* imports OSx imports Ox
and EDG uses shapes in S*
so as Holger suggests it will need to flag this somehow to know..
> - to have some alias mechanism that automatically substitutes one
owl:import with another owl:import so that a SHACL file gets preferred
over a pure OWL file?
I think the need would be some way of choreographing creating a custom
shape, saving it for reuse, and importing it - and either removing the
other imports or providing a flag on custom shapes so that if present
these are preferred over shape libraries or ontologies. This needs to
be scriptable, because we would want to automate it for the general
case of loading D imports O - where D and O are readonly assets -
reference data and ontologies used to support an application domain.
Exploiting EDG workflows to create the new shapes in reviewable mode
would be great - but if we just created the master graphs that would
be fine - we could also manually intervene to review - or set up
additional scripting to create all the review steps.
> - to run the OWL2SHACL algorithm if an ontology seems to contain an
OWL ontology that is not covered by SHACL? If yes, how would it
recognize that.
EDG doesnt seem to function without shapes, so it should be possible
to set up a SHACL validation that looks for instances of classes in a
data graph that do not have shapes, and instances of properties of
those classes not covered by shapes.
NB TBC has a "derive shapes for instances" - AFAICT it allows you to
look at instances - so to use this you need to do a little dance to
create a new file - import the instances (because you dont want to
pollute that) and all all the ontologies - then you seem to need to
manually select all the object types - but this is driven by the
ontology - again if it just selected by default all the classes
represented in the instances and allowed you to deselect the ones of
no interest that would help.
So it would be good if EDG was able to resolve "no shape for data I
have" cases with the derivation of shape graphs for each ontology in
the import tree with data locally represented, and a custom shape
graph that imports these and includes selections.
This is not trivial - so perhaps we could test it in phases:
1) provide a recommended manual recipe for users to create all the
shapes for transitive imports of readonly ontologies and access them
in context (perhaps there is something simpler than the mess I
described above!)
2) allowing users to have the custom shapes override the default
imports in the Ux
3) provide a widget to build a custom shape
4) provide option to automate shape building for imported ontologies
and set up imports
Philosophically, EDG already does import magic for users based on
specific asset types, this allows us to have some control over the
same set of requirements applied to generic asset types.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/cfebfadd-cdc4-d22c-6911-57aed194f146%40topquadrant.com
<https://groups.google.com/d/msgid/topbraid-users/cfebfadd-cdc4-d22c-6911-57aed194f146%40topquadrant.com?utm_medium=email&utm_source=footer>.
UK +44 (0) 7788 561308
US +1 (336) 283-0808
--
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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/11eff17a-553e-4e6e-911e-ce9362184a15%40googlegroups.com
<https://groups.google.com/d/msgid/topbraid-users/11eff17a-553e-4e6e-911e-ce9362184a15%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/8afc4d44-9216-9d87-4888-a1087bfe17e0%40topquadrant.com.
