> 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 topbraid-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/11eff17a-553e-4e6e-911e-ce9362184a15%40googlegroups.com.
