Composer EOL?

[Jan Campschroer]

I heard the whisper that TB Composer is end of life? Is there some formal communication about this?

Grz Jan

[Bohms, H.M. (Michel)]

In the same line: transition options incl. pricing would be very welcome,

michel

--
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.

 

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.

[Matt Goldberg]

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. I really wouldn't want to rely on Studio or have to go back to using Protege for tasks like that. 

[Tim Smith]

While it may have changed, Studio was not available without purchasing EDG server.

I also found Composer easier to use for many tasks, especially using SPARQL.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/6348f836-0f08-4fbc-a56a-ba1c5979eca8n%40googlegroups.com.

[Holger Knublauch]

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.

 

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.

[Steve Ray]

One thing I really miss in EDG Studio is the ability to create (and rearrange) a Graph View that shows instances in my data files with occasional displays of rdf:types. I use such generated diagrams extensively whenever presenting my work. Happy to show some examples if you like.

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/7A5AA147-C011-4D04-AF9D-62629F39529E%40topquadrant.com.

[Holger Knublauch]

On 6 Dec 2023, at 3:07 pm, Steve Ray <st...@steveray.com> wrote:

One thing I really miss in EDG Studio is the ability to create (and rearrange) a Graph View that shows instances in my data files with occasional displays of rdf:types. I use such generated diagrams extensively whenever presenting my work. Happy to show some examples if you like.

Yes please examples. Feel free to send them to me directly if you prefer. We would want to understand where EDG Diagram needs to be improved.

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGUep864d9EbvFtaS1%3D1uFi4m%2BwZ%3DOxf%3Di0EFnTQptarGScBRQ%40mail.gmail.com.

[David Price]

On 6 Dec 2023, at 14:16, Holger Knublauch <hol...@topquadrant.com> wrote:

On 6 Dec 2023, at 3:07 pm, Steve Ray <st...@steveray.com> wrote:

One thing I really miss in EDG Studio is the ability to create (and rearrange) a Graph View that shows instances in my data files with occasional displays of rdf:types. I use such generated diagrams extensively whenever presenting my work. Happy to show some examples if you like.

Yes please examples. Feel free to send them to me directly if you prefer. We would want to understand where EDG Diagram needs to be improved.

EDG Diagrams are a bit like UML diagrams. Classes are different from properties are different from instances - better for classes than for instances. Use case is documentating an ontology.

Graph diagrams are just that … nothing more than nodes and edges whatever they happen to be. Better for instances than for classes. 

I used the graph feature where you could “fix” nodes and generate SPARQL from it … that was great, for example when writing WHERE clauses in a SPARQL CONSTRUCT that was part of an ETL conversion/data migration. 

To do that kind of thing now now in Studio I copy and paste TTL from the Source Code panel into the SPARQL panel to test (but then have to turn URIs into variables).

Cheers,

David

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/4E08418E-E3AD-4FC0-8C7F-3C15C84A4965%40topquadrant.com.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Matt Goldberg]

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:

• 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.
  • Both the Classes and Property views support grouping by namespace/prefix, which doesn't exist in EDG/Studio.
  • I find the Associations view in Composer much more useful for viewing arbitrary hierarchies than the Hierarchy of Selected Asset pane in EDG/Studio.  
  • 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. Also, it works with RDFS/OWL assertions like rdfs:domain and rdfs:range, whereas EDG/Studio diagrams do not.
  • The ability to use lnames instead of labels globally across all views.
  • More SPARQL functionality (prebinding ?this, advanced debugging, not worrying about asset collection URIs, etc.).
  • 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.
  • 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.
  • 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.
  • 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.
  • RDFS/OWL reasoner (which in Composer was done through SPIN, but having the Jena reasoners as additional options would be nice).
  • 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.).
  • The Relevant Properties view in Composer shows relevant properties regardless of how they're relevant (rdfs:domain, OWL restriction, and/or SHACL property shape), 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.
    
• 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.
  • 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.
  • See above about the Relevant Properties view.
  • See above about the Hierarchy of Selected Asset pane, which (I believe) only works for property shapes.
  • You need to declare public shapes or classes for forms to work in data graphs in EDG/Studio. Composer just works with owl:imports.
• 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.
    
• 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.)

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.
• Continued SPIN support for the time being (at least Functions and Rules, I'm not sure about the rest of the SPIN suite)
• 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)
• 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)

[Holger Knublauch]

While we haven’t announced any end of life plans for Composer, we have announced that we are not actively working on further improvements to Composer.

A few versions ago, we had to make the decision to separate the code bases of TBC and EDG, for the benefit of EDG. This means that improvements to the enterprise product no longer automatically made it into TBC.

There is a lot of useful feedback in this thread. We are evaluating various scenarios on how to move forward on the topics of TBC and Studio, so your patience and input is appreciated.

Holger

On 6 Dec 2023, at 11:46 am, Jan Campschroer <camps...@planet.nl> wrote:

I heard the whisper that TB Composer is end of life? Is there some formal communication about this?

Grz Jan

[Holger Knublauch]

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

• • 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.

• • 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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/03ee7f56-81aa-440f-ac8e-45ca1cdffd45n%40googlegroups.com.

[Matt Goldberg]

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.