On 1/6/2015 19:39, Wim wrote:
Hi,
I'm enjoying TBC 4.6 a lot (I really like the features and the UI), as
well as the SPIN java API which is a great companion for automating
some tasks. But there are a couple of (minor) things I've noticed
which, at least from my perspective, would be useful to fix/enhance:
Thanks for your feedback!
* When I specify rules in TBC that contain nodes of the default
namespace (i.e. :myNode instead of myNS:myNode) then SPIN API
complains about these rules. Don't know if this is a problem of
TBC (should sp:text only contain fully qualified nodes?) or of
SPIN API.
What error message are you getting when you use the default namespace?
In general, I would advise anyone against using default namespaces,
because they can easily lead to confusion depending on the order of
subgraphs in a union graph. It is also often confusing to the algorithms
to pick the right choice when a namespace is abbreviated both with ""
and another prefix.
* It would be nice if more "useable" information is sent to the SPIN
API ProgressMonitor, such as the iteration number as an integer
and rule name as a string. Now the only way to extract this
information, seems to parse the so-called subtask label.
Good idea, now recorded on our bug tracker.
* Inferencing with SPIN API is a lot faster than inferencing with
TBC (factor 8 or so). Perhaps the constant updating of the TBC
progress widget is the culprit? If this is the case, maybe it
makes sense to provide the possibility to turn off these widget
updates? Or better yet, perhaps a more advanced progress widget
would allow the possibility to show only "high level" information
such as the current iteration number, and would show additional
information such as a progress bar, busy time, etc.?
Weird, we will investigate.
* In TBC, suppose you create a new ontology that imports other
ontologies, and you create subclasses of existing (imported)
classes. In this case, it would be nice to visualize in the
Classes View which "paths" contain subclasses of the currently
active ontology, and which don't. Just like individuals can be
found very easily due to the "(<number>)" suffix, it would be nice
to see which classes lead to subclasses of the currently active
ontology, and which don't. Perhaps the imported classes that don't
contain subclasses of the currently active ontology could have a
gray font instead of a black one?
In addition to the suggestion by Irene you may also find "Model > Find
all locally defined resources" useful.
* Not sure if it's a legitimate remark or not, but I for one
wouldn't be unhappy to see SPIN API appearing on GitHub...
Absolutely. I have recently started work on a next generation of SPIN as
a candidate proposal for the ongoing Shapes W3C group, and plan to
publish that version as a public github project once the group signals
interest in this work. The complication is that we also need a copy of
this for the TopBraid code base, and branching etc would become very
complicating if this were spanning multiple github projects. My approach
would be to make the edits on the TopBraid code base first, and
periodically copy over the changed files to the public repository. This
will hopefully also allow us to more easily receive external contributions.
But for now I need to ask for patience until the W3C direction has been
clarified.
Thanks again,
Holger
--
You received this message because you are subscribed to the Google Group "TopBraid
Suite Users", the topics of which include Enterprise Vocabulary Network (EVN),
Reference Data Manager (RDM), TopBraid Composer, TopBraid Live, TopBraid Insight,
SPARQLMotion, SPARQL Web Pages and SPIN.
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.
For more options, visit https://groups.google.com/d/optout.
