The problem probably isn't in the closed world of Composer but in the more
complicated world of interacting with different data sources. I have seen
scenarios where Composer is having profound difficulty with unicode
characters, requiring the kind of transformations that Courtland describes.
These aren't fantasies. For example, what if you want to import the content
of a file from the web into labels, comments, or descriptions (or other
properties) in Composer. The content might very well be encoded as UTF-8 or
Unicode. Were it written in Composer it might be handled fine, but when
imported it might not. Same for export. What if you want to write an SWP
that constructs XML/HTML or even Latex. What you see in Composer might be
fine but the content produced might not. We live in a world that requires
interaction and integration with different data sources, and for Composer
to be truly useful (to truly shine) it must be able to accommodate these
interactions and integrations seamlessly. That is more or less how I
interpret Courtland's comment/lament.
Jack
On Thursday, November 1, 2012 3:08:57 PM UTC-7, Bob DuCharme wrote:
Hi Courtland,
TopBraid Composer has full Unicode support. I just used a text editor to
create a Unicode UTF-8 Turtle file that included both the name Schrödinger
and some Kanji characters and TopBraid Composer opened the file and
displayed the non-ASCII characters just fine.
Do you know what encoding your file was in?
Bob
On Thu, Nov 1, 2012 at 5:35 PM, ceyockey
courtlan...@astrazeneca.comjavascript:
wrote:
There are two discussion threads already present here which include
mention of Composer's not handling character encoding well; these are from
2011. What I am trying to do is simply conduct an Import Triples from
this File into current Model from a Turtle file (.ttl) into an RDF file
(.rdf). I've had problems with doing this due to some bizarre characters
in the inputs, which I am manually removing or transforming. However, I
came across a skos:prefLabel with the value Schrödinger software which
results in a Could not inspect file... error.
The workaround for this which I will need to use is encoding the ö as
the HTML/XML equivalent #246;. This will at least preserve the
content in a form which can be reconstructed, but this is far from ideal.
One could presumably use the Unicode equivalent of U+00F6, but this would
present problems due to it's not being a delimited token as the HTML/XML
value is.
I am wondering when you might be able to release a Composer client which
includes support for extended Latin character sets which contain the most
commonly used non-ASCII characters such as this one?
Thanks --Courtland Yockey
--
-- You received this message because you are subscribed to the Google
Group TopBraid Suite Users, the topics of which include Enterprise
Vocabulary Network (EVN), TopBraid Composer, TopBraid Live,
TopBraid Ensemble, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to
topbrai...@googlegroups.com javascript:
To unsubscribe from this group, send email to
topbraid-user...@googlegroups.com javascript:
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
--
-- You received this message because you are subscribed to the Google
Group TopBraid Suite Users, the topics of which include Enterprise Vocabulary
Network (EVN), TopBraid Composer, TopBraid Live,
TopBraid Ensemble, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to
topbraid-users@googlegroups.com
To unsubscribe from this group, send email to
topbraid-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
