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)
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 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/03ee7f56-81aa-440f-ac8e-45ca1cdffd45n%40googlegroups.com.
