Thanks, I wasn't aware of a few of those features. I'll have to check them out.
But to summarize my perspective though, for RDF power users who - may be working with or other tools/triple stores than EDG (or are working with EDG), - don't need any of the extra capabilities like multiple users, governance, or web services that Studio is designed to provide, and - are interested in working with more than SHACL vocabularies, Composer is a much faster, lighter weight, and more convenient tool, and Composer does a great job at it (despite the limitations of the open-world support). It's like an IDE for the entire Semantic Web, not just for EDG. I am not aware of another tool out there that is anywhere close in capability to and can really compete with Composer. It's certainly a lot better than Protege unless your primary focus is OWL reasoning, and even then I would often work on ontologies in Composer and then only use Protege to verify they were correct and consistent. Even the free version of Composer is far better than other tools I've tried. It seems that Composer is a unique product with no real competitors, so I'd be sad to see it permanently discontinued. On Thursday, December 7, 2023 at 4:32:52 AM UTC-5 Holger Knublauch wrote: > Thank you Matt. There is a lot to process here but let me try to do my > best... > > On 6 Dec 2023, at 7:54 pm, Matt Goldberg <mgbe...@gmail.com> wrote: > > I see EDG/Studio and Composer solving two completely (or largely at least) > separate problems. EDG is great for enterprise data governance and for > exposing RDF-based data to those who are not and do not need or want to be > RDF experts. It has a lot of great advanced features, a simplified UI, > asset collections with workflows and change history, governance and access > management, web services, and so on. Composer, on the other hand, is a > nearly ideal tool in my opinion for advanced RDF users and developers > working on knowledge graphs when EDG and Studio (i.e. data governance and > web services) are not needed. I think of it as a *separate tool instead > of the IDE for EDG* as it used to be marketed as. Here are some examples > of what I mean: > > > Many of these points are because TBC started before SHACL was created and > therefore began with RDFS/OWL. SHACL was added as an afterthought (after > SPIN). Thus many UI features are (for better or worse) working in both > worlds. With EDG and Studio we made a conscious choice to focus on SHACL > and have some limited OWL/RDFS support only. The problem with supporting > both worlds equally is that you end up with slower and more complex > algorithms, and cause further confusion, need to multiple training > materials etc. You, as a veteran user, may have other preferences than > newcomers who just want to model classes and properties. Also note that a > lot of downstream features rely on SHACL, e.g. the GraphQL generation. > > And don't get me started on the semantic differences between RDFS/OWL and > SHACL, e.g. open world vs closed world. What TBC does with RDFS/OWL was > always kind-of incorrect and only a hack in the absence of a better > alternative. > > > - Composer has a lot of features that I like that are different or > missing in EDG/Studio, for example: > - The Properties view- there is no property hierarchy view in > EDG/Studio. > > The reason is that SHACL does not use rdfs:subPropertyOf, so showing the > hierarchy is not mission-critical. EDG does have the RDF/OWL Properties > List panel > > [image: PastedGraphic-1.png] > > > > - > - Both the Classes and Property views support grouping by > namespace/prefix, which doesn't exist in EDG/Studio. > > If I remember correctly, TBC would flatten these trees into just two > levels of hierarchy. The closest approximation in EDG would be to use the > Class List or RDF/OWL Properties List panel and then switch to displaying > qnames. Then at least they show up below each other. > > [image: PastedGraphic-2.png] > > > - > - I find the Associations view in Composer much more useful for > viewing arbitrary hierarchies than the Hierarchy of Selected Asset pane > in > EDG/Studio. > > Is this still the case after, with 7.7, the Asset Hierarchy panel now > supports selecting a single property? We also made further improvements to > that panel with 7.8 so this may be worth another look. If you still find > features missing, please clarify which. > > > - > - Although the Diagram and Graph features in Composer don't look as > nice as what is available in EDG/Studio, it is faster, easier to use, > and > gets me what I'm looking for much more quickly. > > Yes we have heard this before and need to revisit the EDG Diagram. > > > - > - Also, it works with RDFS/OWL assertions like rdfs:domain and > rdfs:range, whereas EDG/Studio diagrams do not. > > See above, this is not high on our radar. > > > - > - The ability to use lnames instead of labels globally across all > views. > > Almost all panels in EDG now have a button to switch between labels and > qnames, but for 8.0 I was already planning to add a button to switch > everything at once, including the form panel. So this may be addressed soon. > > > - > - More SPARQL functionality (prebinding ?this, advanced debugging, > not worrying about asset collection URIs, etc.). > > The SPARQL panel also pre-binds ?this automatically. > We don't have a SPARQL debugger in EDG but we have the button to show the > Algebra and the optimizations. > For my information, what do you mean with not worrying about asset > collection URIs? > > > - > - Running all test cases and viewing results is easier in Composer, > instead of in EDG/Studio having to go to the admin page and getting a > giant > Turtle dump. > > Yes Ok, I wasn't aware that many people would use that particular feature. > If you want a better experience, you could create a file that owl:imports > your test case files and use the Problems and Suggestions panel. > > > - > - I find the Annotations Template capability in Composer very > useful. I assume that evolved to the URI generation rules and new > resource > forms in EDG, but the ability to customize which properties are used > and > have the templates fill certain bits in are super convenient. > > Right, that doesn't exist in EDG. EDG does support Constructors, see > https://archive.topquadrant.com/doc/latest/ext/points.html?highlight=constructor#constructors > Having this information as part of the model is arguably cleaner than only > storing the tempates in the UI, but I agree it requires some set up first. > > > - > - The ability to use different default annotation properties. As > far as I am aware, all Asset Collection types in EDG/Studio only use > rdfs:label and rdfs:comment as the only default label and description > property (except for Taxonomies which use skos:prefLabel and > skos:definition instead). If I wanted to use, e.g., skos:prefLabel and > dcterms:description for labels and descriptions, EDG/Studio isn't > really > set to handle it conveniently. > > Yes we hear this requirement quite often. You can already customize the > forms/view shapes for everything using SHACL, but the Create dialogs are > usually hard-coded against rdfs:label. This needs to improve. > > > - > - Shortcuts in Composer like typing "{@en}" at the end of a string > literal to set a language tag and right-clicking on the form or > dragging a > property to the form to add a new field for a property are very > convenient. > > Right. > > > - > - RDFS/OWL reasoner (which in Composer was done through SPIN, but > having the Jena reasoners as additional options would be nice). > > EDG does not have the notion of inference graph that TBC had, and TBC had > it easier because it was originally designed for single users and in-memory > graphs only. The Inferences panel can be used to execute rules and assert > triples. We don't have plans to bring back OWL or RDFS reasoning as they > usually don't perform well. > > > - > - Composer used to have a Git integration that worked fairly well > and integrated with Composer itself (showed branch name and showed > files > with changes in the Project Explorer, had convenient right-click menu > and > views for doing comparisons and starting commits, etc.). > > Yes, we got that free by being based on Eclipse. But I use Git all the > time from EDG Studio. I just use GitHub Desktop or VS Code instead of > Eclipse and then, occasionally, do a workspace refresh from the Files page. > To be honest, I think Eclipse is not maintained well anymore and is on the > way out. > > > - > - The Relevant Properties view in Composer shows relevant > properties regardless of how they're relevant (rdfs:domain, OWL > restriction, and/or SHACL property shape), > > Again, this is OWL vs SHACL. > > > - > - while the closest capability in EDG/Studio is the Property Groups > pane but that only works for SHACL property shapes and is only visible > in > ontology asset collections. > > I was just wondering about the same thing: does it really make sense that > the choice of Panels depends on the selected asset collection type? I > personally would also like to use various Ontology-specific panels from > Taxonomies, if only to look up things. We should have an option to just > show all Panels. I have recorded a ticket. > > > - While EDG/Studio has a lot of neat UI features that are dependent on > SHACL, for the persona of an advanced RDF user doing general RDF work, I > feel that it is *too* dependent on SHACL. For example: > - There's little support for RDFS/OWL vocabularies in EDG/Studio. > SHACL shapes needed to be added to these for data expressed using them > to > appear correctly. > > FWIW I am this week working on streamlining the import process so that > having the shapes becomes easier. For example there will be a New button > where you start with uploading an RDFS/OWL file and it will produce the > SHACL ontology automatically. Will look into batch operations for multiple > files too. > > > - > - Composer always creates fields for every "relevant" property on > form views. If a resource has a value for a property, it's on the form. > If > there is a relevant property shape for a property, it's on the form > with > the proper name. If there is a property with a rdfs:domain that is in > scope > for the resource, it's on the form. If there is an OWL restriction that > is > in scope for the resource, it's on the form. EDG/Studio only does form > entries for property shapes, and it can also show extra properties but > that > set of extra properties is not editable. > > The extra properties are not editable because they lack definitions such > as sh:datatype and sh:class. Overall this is the usual RDFS/OWL vs SHACL > topic. > > > - > - See above about the Relevant Properties view. > - See above about the Hierarchy of Selected Asset pane, which (I > believe) only works for property shapes. > > See above. > > > - > - You need to declare public shapes or classes for forms to work in > data graphs in EDG/Studio. Composer just works with owl:imports. > > Yes but Composer also doesn't offer a GraphQL endpoint, nor a way to limit > which instances CAN be edited. It's a trade-off. But this doesn't affect > you when you're on Studio and open files. You can edit any instances there. > > > - Editing files in EDG/Studio is a bit of a hassle if you edit a lot > of files simultaneously. > - I find that the Asset Collection overhead is often unnecessary. > - You have to ensure that changes are saved to file. > - You have duplicate file/asset collection pairs while files are > open for editing. > - You have to remember to use asset collection graph URIs when > querying open files- Composer always uses the graph/ontology/file > URI for > named graph URIs. > - You have to open up each file for editing in EDG/Studio and have > a lot of browser tabs open. It's much more convenient to have multiple > files open in Composer. > - Refactoring across files is much more convenient (and is usually > automatic) in Composer, which doesn't happen across files and/or asset > collections in EDG/Studio. > > Right, this is a major point and we need to improve on this. Maybe Studio > should open all files that are owl:imported as (temp) asset collections > too, and then apply refactorings to those instead of the files. If anyone > has ideas, let me know. > > > - There are a lot of fantastic features in EDG/Studio that are great > for the purpose EDG/Studio serves but in my opinion are *not* > necessary for a tool for RDF power users, such as: > - Asset Collections and Workflows > - Any of the other governance assets or governance framework > - Users and access control > - Simplified, end-user facing UI- I'd rather have the power of > Composer than the sleekness of EDG/Studio for advanced work or > investigating files. > - A *separate* web UI (if the entire Composer UI was rendered in a > browser, that's fine. It shouldn't have the whole EDG service like it > used > to before version 7.) > - Web services (e.g. all the ADS services, all the SWP services, > etc.) > > Yes sure, you can ignore these features from Studio if you don't need them. > > I'm not by any means saying there are problems with EDG- it is fantastic > at what it does. It's just that in my opinion Composer could serve a > different purpose for a different set of users. > > Also, there are definitely features that both should have in my opinion, > such as: > > - Full SHACL support, including Functions and Multifunctions in SPARQL > queries, rules, and property value rules. > > No plans to update TBC for these. Way too much work for too little > benefits. The sales volume of TBC isn't big enough to make this realistic. > > > - Continued SPIN support for the time being (at least Functions and > Rules, I'm not sure about the rest of the SPIN suite) > > We continue to use SPIN functions and magic properties ourselves, so these > are not going away. But even those COULD be expressed in SHACL now, so SPIN > is now completely redundant. We are of course trying not to break things > for long-term customers but at some stage need to move on. > > > - The same basic suite of utility SPARQL functions (e.g. ui:label) > - ADS support (in Composer, the ability to run ADS-based functions and > constraints, just the basic API, and script editor would be sufficient for > me) > > Sorry, no way this is going to happen. In general, I would much rather > spend time improving Studio (and thus EDG in general) than to backport > complex features such as ADS to TBC. > > > - Graph visualization > - The ability to push a project to EDG (i.e. from both Composer and > Studio) > - Importing data from external sources (e.g. databases/spreadsheets > like EDG can do now and D2RQ/spreadsheets like Composer used to do) and > viewing external data (e.g. EDG's remote data sources and Composer's > SPARQL > Endpoint Connection Files) > > EDG now has far better support for SPARQL endpoints than TBC ever had, see > https://archive.topquadrant.com/doc/latest/user_guide/remote/index.html > > Thanks > Holger > > > On Wednesday, December 6, 2023 at 8:11:59 AM UTC-5 Holger Knublauch wrote: > >> >> On 6 Dec 2023, at 1:55 pm, Matt Goldberg <mgbe...@gmail.com> wrote: >> >> I'd be really disappointed if that were true. Composer is (in my opinion) >> by far the best general purpose RDF power user tool out there. EDG is >> great, but Composer is much better for quickly opening up files, inspecting >> them, and making edits at a low level. It's also much easier to deal with >> files in Git with Composer than with Studio. >> >> >> Thanks for your feedback. Leaving aside TBC for now, what are the >> obstacles to using Studio with Git right now? When you save files from >> Studio, they are also written with the sorted TTL writer. In fact I am >> entirely using Studio for all edits that I make to our own ontologies such >> as dash. >> >> For making edits at low level, note that the Source Code panel of Studio >> has a button to see and edit the whole graph at once. What else is TBC >> doing better? >> >> Holger >> >> >> I really wouldn't want to rely on Studio or have to go back to using >> Protege for tasks like that. >> >> On Wednesday, December 6, 2023 at 5:56:44 AM UTC-5 Bohms, H.M. (Michel) >> wrote: >> >>> In the same line: transition options incl. pricing would be very welcome, >>> >>> michel >>> >>> >>> >>> *From:* topbrai...@googlegroups.com <topbrai...@googlegroups.com> *On >>> Behalf Of *Jan Campschroer >>> *Sent:* woensdag 6 december 2023 11:46 >>> *To:* TopBraid Suite Users <topbrai...@googlegroups.com> >>> *Subject:* [topbraid-users] Composer EOL? >>> >>> >>> >>> I heard the whisper that TB Composer is end of life? Is there some >>> formal communication about this? >>> >>> >>> >>> Grz Jan >>> >>> -- >>> The topics of this mailing list include TopBraid EDG and related >>> technologies such as SHACL. >>> To post to this group, send email to topbrai...@googlegroups.com >>> --- >>> 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/de98f211-1b86-4c6a-983d-73382c62e32en%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/topbraid-users/de98f211-1b86-4c6a-983d-73382c62e32en%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> This message may contain information that is not intended for you. If >>> you are not the addressee or if this message was sent to you by mistake, >>> you are requested to inform the sender and delete the message. TNO accepts >>> no liability for the content of this e-mail, for the manner in which you >>> use it and for damage of any kind resulting from the risks inherent to the >>> electronic transmission of messages. >>> >>> >> -- >> The topics of this mailing list include TopBraid EDG and related >> technologies such as SHACL. >> To post to this group, send email to topbrai...@googlegroups.com >> --- >> 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/6348f836-0f08-4fbc-a56a-ba1c5979eca8n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/topbraid-users/6348f836-0f08-4fbc-a56a-ba1c5979eca8n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> > -- > The topics of this mailing list include TopBraid EDG and related > technologies such as SHACL. > To post to this group, send email to topbrai...@googlegroups.com > --- > 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/03ee7f56-81aa-440f-ac8e-45ca1cdffd45n%40googlegroups.com > > <https://groups.google.com/d/msgid/topbraid-users/03ee7f56-81aa-440f-ac8e-45ca1cdffd45n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- The topics of this mailing list include TopBraid EDG and related technologies such as SHACL. To post to this group, send email to topbraid-users@googlegroups.com --- 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/28b2aee8-e745-46e5-b42a-032f1401c3bdn%40googlegroups.com.
