Hi David, A few thoughts below.
On Tue, Feb 22, 2022 at 9:57 AM David Price <[email protected]> wrote: > Hi Tim, > > A few further opinions below. > > On 22 Feb 2022, at 13:41, Tim Smith <[email protected]> wrote: > > Hi David, > > Thank you for the clarification. My impression of TeamWorks was > different. This feels like "open loop control" of a closed loop process > given that one workflow can overwrite another unless strict human processes > are followed. My use case requires branching and versioning with > "github-like" functionality where multiple people/roles can edit the same > graph with conflicting edits reconciled at commit time. > > > IMO thinking of ontologies as software artefacts is a good approach. > However, assuming that ontologies (RDF graphs), can be versioned and > diff'ed using the same approach as say Java source code (sequences of lines > of text) does not seem to me like a good way to start. In RDF-land, even > ontologies are actually data. The defiition of “conflicting edits” is also > a big one as things that conflict in RDF-land can be completely unrelated > as far as a normal diff tool is concerned. > > I was definitely *not* thinking of diff as in a textual difference operation. My reference to Github was intended to be an analogy not a literal interpretation. I believe the concepts of branching, diff'ing and merging apply both to code and graphs with the implementation being wildly different. Comparing graphs at the triple level, including handling b-nodes properly was what I was thinking, thus my reference to the TBC Diff engine. > We have a need to have versions of both ontologies and instance data with > compatible versions linked together. > > > Of course, everyone has that requirement who’s ever used an ontology at > all. However, a tool cannot do all the heavy lifting. For example, if your > ontology changes to make existing data invalid then some sort of data > migration/transformation is needed. > > The simple addition of "<x> sh:minCount 1” in a SHACL property shape can > make millions of data instances invalid and no diff tool will find that. > > Only good business processes outside anything in EDG, or any other tool, > can properly support this in the general case. > > I wasn't thinking of a tool to manage the transformation of instance data from one ontology to another. I agree, that would be a real challenge. I was thinking of simply ensuring an instance graph can know what version of an ontology it was populating. This requires defining versions of ontologies beyond putting a "v<X.x>" in the name of the ontology graph.. This could be inferred from the import statements or a specific predicate could be used to point to the defining ontology. While I'm not looking for this capability here, I am a fan of using a transformation ontology to define the transformations and a SPARQL/SPIN/SHACL engine to execute them. I have built such an ontology and have used it successfully a number of times. I believe this was also the strategy behind the Spinmap Mapping technology in TBC. > > Since all edits can be controlled through EDG (vs Git where the individual > changes have to be detected and reconciled), maybe an extension of the TBC > Diff engine might help here? > > > As I mentioned, in a working copy you are not actually changing a graph. A > working copy is a layer of changes (literally additions and deletions) to > be applied over the production copy that the UI make look like normal > triples when viewing thru the lense that is the working copy. That said, we > are looking at potential improvements. > > I understand. Fundamentally, I think of a "working copy" as originating from the production graph at a specific point in time (i.e. a "branch" in the version tree), even if the graph isn't duplicated. I think the risk in the current design is that the layer of changes is currently defined as anything the user has entered as a change since the working copy was created. As you said, working copies do not know what changes other working copies have committed to the production graph. So if you make changes, and I make changes, if I commit first, your changes can overwrite mine and vice versa. What's also confusing, currently, if this happens, your changes will show up in my working copy (because it's just loading the latest production graph). BUT, when I run the Comparison Report in my working copy, which explicitly says "*Compares this working copy with the production copy*", it only shows the changes I have entered even though the production copy has changed since my workflow was initiated. Maybe I worked with version control systems for too long, LOL??? While this can be managed at the work process level, it would be better to prevent the occurrence within EDG. For example, when a Working Copy is displaying the changes, it could show all proposed changes (from my working copy) as well as all committed changes that have occured since the working copy was initiated (EDG *should* have the change history but maybe there are edge cases?). Changes that conflict could be highlighted. Conflict definitions could be defined in an ontology, much like the TBC Diff engine. >From TBC help: The Diff Engine TopBraid's Diff engine is entirely declarative and can be modified or extended to get customized output. The various diff classes have SPARQL queries attached to them via diff:rule. These queries are called by the engine to create the instances of this class. The GRAPH keyword of SPARQL is used to query the old graph versus the new graph. If you want to add your own kinds of diff outputs, then simply add such diff:rules. The second step of the Diff engine is to call all spin:rules for the constructed instances of the diff classes. These rules can be used to post-process the raw output from the first step, e.g. to create human-readable labels. The same mechanism can be used to create higher-level diff objects from the lower-level triple change objects. You can modify the diff.ttl file in your workspace to adjust the behavior of the diff engine for your needs. > > Anyway, I was hoping to use versioning/diff reconciliation to help justify > the cost of EDG. I do not have a TSM at the moment. What is the best way > to submit a feature request? > > > I’ll talk to you off forum. > > Cheers, > David > > > Thanks, > > Tim > > On Mon, Feb 21, 2022 at 4:19 AM David Price <[email protected]> > wrote: > >> A working copy cannot “see” another in EDG. The word “copy” is misleading >> in that it is not a copy at all but is a set of changes to be applied. The >> UI makes the changes appear as real triples but they are not. So, not >> really comparable to git at all. >> >> Customers today handle this kind of issue by being reviewers or editors >> on both workflows and by business process management of work tasks (eg >> daily scrums and using chat tools). >> >> There is work on this topic for the future so if you have detailed use >> case you can share it would be great to submit a feature request thru >> Support so it can be considered as part of that effort. >> >> Cheers, >> David >> >> On 18 Feb 2022, at 20:51, Tim Smith <[email protected]> wrote: >> >> >> Hi, >> >> I am exploring the robustness of change management within the EDG working >> copy process. >> >> When I open two workflows at the same time from the same production graph >> and make changes that are intended to conflict, I don't see any conflict >> detection or resolution. >> >> For example: >> In WF #1, I delete instance :inst1. >> In WF #2, I add the triple {:inst1 :getsDataFrom :inst2.} >> >> I commit WF #1 first, deleting :inst1 and removing all triples about >> :inst1. >> >> When I commit WF #2, the {:inst1 :getsDataFrom inst2 } triple is added >> but is essentially a "hanging" triple because everything else about :inst1 >> has been deleted by WF #1. >> >> I was thinking that WF #2 would check to see if the production graph had >> been changed and surface all the changes between the WF #2 working copy and >> the current production graph, not the production graph WF #2 originated >> from. >> >> I also noticed that after committing WF #1, when I ran the "See >> Changes/Comparison Report" in WF #2, the full URL for :inst1 was displayed >> instead of the label indicating that this report is "sort of" running >> against the new production graph created by committing WF #1 (i.e. the >> :inst1 rdfs:label triple is gone). HOWEVER, I see the new triple as the >> only change even though other changes have occured to the production graph >> via WF #1. >> >> Is my understanding of how EDG handles simultaneous workflows correct? >> If so, should multiple working copies be permitted? Can this process be >> changed so conflicts can be detected and resolved between multiple working >> copies (more like how GitHub works) >> >> This is critical functionality to a large use case that I am exploring. >> >> Thanks, >> >> Tim >> >> >> -- >> 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/CAF0WbnLbWWJoc%2BE3vOAiCvLRVtNhvUvBPiEJdH32dZ1McZu0nw%40mail.gmail.com >> <https://groups.google.com/d/msgid/topbraid-users/CAF0WbnLbWWJoc%2BE3vOAiCvLRVtNhvUvBPiEJdH32dZ1McZu0nw%40mail.gmail.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/7A145419-9C78-4C75-8144-9436E99CBDCF%40topquadrant.com >> <https://groups.google.com/d/msgid/topbraid-users/7A145419-9C78-4C75-8144-9436E99CBDCF%40topquadrant.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/CAF0WbnK%2BTQUYvp1%2B%2B3V8MXSZujq8z8_FXifFycNmgwXBL1vDWQ%40mail.gmail.com > <https://groups.google.com/d/msgid/topbraid-users/CAF0WbnK%2BTQUYvp1%2B%2B3V8MXSZujq8z8_FXifFycNmgwXBL1vDWQ%40mail.gmail.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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/EEB5D695-A7B4-43A7-89EC-563247F17BDF%40topquadrant.com > <https://groups.google.com/d/msgid/topbraid-users/EEB5D695-A7B4-43A7-89EC-563247F17BDF%40topquadrant.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/CAF0WbnLjPLzrPmQ%3DeeT56_GmbaxSrNE0D3UC8A6e%3DmMmVZG0Ag%40mail.gmail.com.
