managing local resources (new resources created in EDG) in a proxied EDG asset - writing new resources created in a proxied graph back to a local file or the original proxied source

[Simon Opper]

Hi All

This picks up the previous thread on loading graphs in EDG via a data driven approach and especially the intent of using proxies for source graphs to segregate production data and models.

We are now looking how this deals with CRUD  of "development instances" - Abox or other graph "edits" Tbox that are made in the proxied EDG asset but need to be written back to the source graphs or to staging/review graphs.

So we now have EDG consuming a source graph  A  as a proxy into an EDG graph B.

What we need to do now is write any new resources created in the EDG asset B back to:

1. to the source A : and/or

2 to a staging graph C

3. to/via a teamwork workflow D to review the changes back to C or A

Sure I can export the data from the EDG gui, or extract it via TBCME but I want a data driven approach. 

I'm hoping for a way to trigger this write back process on an event in the EDG asset GUI of B 

e.g. this could be:

1. at a minium before the EDG asset B is deleted or cleared

2. before an external proces forces the asset B to be deteled or cleared -  we can trigger the purging of assets and reloading via a set of rules.... so can this trigger the write back before they are nuked

3. happy case - use a shacl rule that can be clicked or run via GUi when some action or change triggers it

4. future case -  when the seletion focus of some carefully selected page UI object(s) changes

Is there a logical starting point to acheive the above ?

Many thanks in advance

Simon

[Holger Knublauch]

Hi Simon,

this sounds difficult to get right. Just to make sure you know about https://doc.topquadrant.com/6.3/developer-guide/ => Event-Condition-Action Rules? These teamwork:EditRules can in principle react on arbitrary triple patterns. A similar approach would be to follow the Change history and try to replicate (certain/all) changes to another repo.

But there are so many ways in which things may be edited, e.g. a resource may loose its triples step by step rather than through a single operation. I guess replaying the edits from the change history is probably the most complete/least risk approach.

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/ddba1927-a3ac-49e4-aa7c-9fc10567ac44o%40googlegroups.com.

[Rob Atkinson]

Probably what is require is a means to interact directly with GIT from EDG, mirroring the equivalent capability in TBC via the ECLIPSE/GIT integration.  Custom code to write to EDG Asset collections can be written - provided the change detection logic is good enough - but it still doesnt make the content reusable in another context.

[Holger Knublauch]

One area that we are planning to work on for 7.0 (end of year) will be better round-tripping between files (which then may also be on Git) and the graphs. A goal of this is support for running EDG locally just like TBC-ME runs today, having users point at a workspace folder and then seamlessly switch between TDBs and files, maybe with a "Save" button that makes it easier to export the TDB, and a "Reload" button that would pull the latest version from the file into the TDB. This is part of the strategy to move more and more pure "TBC" functionality into the web product, with the web product also executable on a local hard-drive as a "personal" edition.

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/4cbb3846-67e4-46fd-a83b-dd356dcbf98co%40googlegroups.com.

[robatki...@gmail.com]

+1 - sounds like what I was getting at! Good to hear (and defer worrying about a solution for now!)