That’s a terrific point. I neglected to mention how clueless I’ve been regarding best practices for not only managing the tests but also the shapes themselves. There are many organization questions along the way, and more often than not my choices would be hard for me to support. For instance, I keep my shapes in different files and not alongside the schema. Further, shapes have their own IRIs. I do this from some instinct that keeping everything separate will prove valuable at some point in the future, but it is much more work to manage.
I’m curious how (and why) others are organizing all of these artifacts. -Adam On Jan 6, 2019, at 3:50 PM, Holger Knublauch <[email protected]<mailto:[email protected]>> wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. FWIW on the naming/organization of validation tests, here is an example of how I have arranged the tests that later became part of the official SHACL test cases library: <padenjkidkdmkehn.png> Basically there are folders for each category and files for each constraint type that is being tested. In your case, maybe you have a number of classes/shapes to test, each with individual constraints. You could create small example instances and put those into the test case files themselves, one file for each class. An alternative design is to create larger instance files (data graphs) and owl:import them into the test case files. The latter makes it easier to reuse definitions but also carries the risk that changes to the data graph break existing tests. Holger On 7/01/2019 3:00 am, Kimball, Adam wrote: Yes, that helps a ton! I never knew about the individual resource conformance check - that is awesome. I’ve just been making validation tests. It’s incredibly helpful to define failing tests and then validate they continue to fail. However, I feel like my ability to name / manage and have confidence in these tests isn’t great. Maybe just because I’m new to the process. I would really appreciate a webinar or even document on how Composer (and EDG) can be used as a development environment for SHACL. So, less about SHACL itself and more about the tools and ways to accomplish our goals. Thanks again, Adam On Jan 3, 2019, at 4:02 PM, Holger Knublauch <[email protected]<mailto:[email protected]>> wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 4/01/2019 5:59 am, Adam Kimball wrote: I'm looking to maximize my understanding of Composer's features related to writing, running, reporting, and testing of SHACL. The online help docs don't appear to treat this subject much, or at least, I couldn't find it. Here are some basic questions: 1. Can I show conforming SHACL shapes in the SHACL Validation window? 1. I know that there is an option for showing conformance in the Targets windows but I'm not using Targets but maybe I should be? I never see anything in that window.. 2. I know I can get the full output but then I end up with a new graph to get rid of etc. 3. I'm just looking to approximate the experience of running unit tests where I can see (for example) that all of my tests or suites ran. On the Targets View (assuming you have activated "Target View shows conformance" in the TBC SHACL preferences), it does show the conformance if the selected resource is a class (that is also a node shape). For the schemashacl-violations.ttl example, I see <kjdclablplmpgddd.png> For an individual resource, it should help to activate the <nmgkgioelklepklp.png> button in the toolbar. If there are violations, you'll see something like <bddlhpnlplgbjhgo.png> in the upper right corner of a resource form. Otherwise, the icon is greyed out. 2. The new unit tests feature is awesome and I've begun to utilize it but don't know if i have the right workflow 1. For instance, say I have existing test but want to add some additional tests to it. It seems like the only way to do this is to drop the test and rebuild it from the "Create a test case" button but that leaves me a little uncertain. I really just want to add a test, ideally in another suite. Can someone describe their workflow for writing tests? The workflow is different for each kind of test. Examples: - For validation tests, use the corresponding button in the SHACL Validation window. Note that there can only be one validation test per file, because re-running the test means to perform validation of everything in that graph (and in particular its imports). - For SPARQL query tests, use "Turn into test case" from the context menu of the SPARQL view. - For SPARQL expression tests, highlight an expression in the SPARQL view and right click to get "Turn into dash:FunctionTestCase". In the latter two cases, you can define any number of tests in the same file/graph. There are other test case types, see the subclasses of dash:TestCase. Which test case types are you particularly interested in? Holger Thanks everyone. I feel strongly that SHACL has the possibility to really move things forward and I am excited to become expert in it. Feel free to chime in on how YOU use the software, this isn't just for the TQ folks. -Adam -- 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]>. For more options, visit https://groups.google.com/d/optout<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwMFaQ&c=q6k2DsTcEGCcCb_WtVSz6hhIl8hvYssy7sH8ZwfbbKU&r=c31WRmngRl-Ei5FxoVl5JYQYy1t5NE6gKgMbp1GhG5M&m=IGA3X13IosDlPphlffaIAZZxan-P2F8jkjuvdLUEmfg&s=cRI6Tqzm_7hkO3dmyB3kZvBV4-drSHlXA0l5fg1kqTw&e=>. -- 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 [email protected]<mailto:[email protected]>. For more options, visit https://groups.google.com/d/optout<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwMFaQ&c=q6k2DsTcEGCcCb_WtVSz6hhIl8hvYssy7sH8ZwfbbKU&r=c31WRmngRl-Ei5FxoVl5JYQYy1t5NE6gKgMbp1GhG5M&m=IGA3X13IosDlPphlffaIAZZxan-P2F8jkjuvdLUEmfg&s=cRI6Tqzm_7hkO3dmyB3kZvBV4-drSHlXA0l5fg1kqTw&e=>. -- 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 [email protected]<mailto:[email protected]>. For more options, visit https://groups.google.com/d/optout<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwMFaQ&c=q6k2DsTcEGCcCb_WtVSz6hhIl8hvYssy7sH8ZwfbbKU&r=c31WRmngRl-Ei5FxoVl5JYQYy1t5NE6gKgMbp1GhG5M&m=XfuO5VAtWXvwtIlLLfBfQkaK67swcFSTa0rHm2zfYDU&s=MlWP_RAnsQ-w1qq9WIUYzv5A5ynu28yz_oM8wtILBX4&e=>. -- 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 [email protected]<mailto:[email protected]>. For more options, visit https://groups.google.com/d/optout<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwMFaQ&c=q6k2DsTcEGCcCb_WtVSz6hhIl8hvYssy7sH8ZwfbbKU&r=c31WRmngRl-Ei5FxoVl5JYQYy1t5NE6gKgMbp1GhG5M&m=XfuO5VAtWXvwtIlLLfBfQkaK67swcFSTa0rHm2zfYDU&s=MlWP_RAnsQ-w1qq9WIUYzv5A5ynu28yz_oM8wtILBX4&e=>. -- 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]. For more options, visit https://groups.google.com/d/optout.
