Re: [sword-devel] Parsing Strong's to support more flexible layout in user interface
On 11/10/19 4:36 PM, Tobias Klein wrote:
Is there any other Sword frontend as of today that is working with the
Entry Attributes for any dictionaries?
Xiphos uses getEntryAttribute for preverse headers, footnotes, and
xrefs, no matter the module type.
For comparison, StrongsRealGreek and StrongsRealHebrew are ThML modules
in which what your display shows as "Related" appear as direct links in
the text itself. In Xiphos, those links are treated as hover-hot to make
xrefs appear in sidebar; click replaces the current pane entry with the
new choice.
Samples using your example:
http://ftp.xiphos.org/sword/xiphos/dictionary-link/
Rendered from this source content:
$ diatheke -b StrongsRealGreek -k 846
00846: 846 αὐτός [AU)TO/S] {autós}
\ow-tos'\ from the particle αὖ [AU)=] {aû} (perhaps
akin to the base of 109
through the idea of a baffling wind) (backward); the reflexive pronoun
self, used (alone or in the comparative href="sword://StrongsRealGreek/01438">1438) of the third person ,
and (with the proper personal pronoun) of the other persons:--her,
it(-self), one, the other, (mine) own, said, (self-), the) same, ((him-,
my-, thy- )self, (your-)selves, she, that, their(-s), them(-selves),
there(-at, - by, -in, -into, -of, -on, -with), they, (these) things,
this (man), those, together, very, which. Compare href="sword://StrongsRealGreek/00848">848.
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Parsing Strong's to support more flexible layout in user interface
Hi Troy,
Thanks for your response on this! There's still a lot for me to learn
regarding the Sword engine.
Never heard about TEI before, I need to read up on this!
Is there any other Sword frontend as of today that is working with the
Entry Attributes for any dictionaries?
Best regards,
Tobias
On 11/9/19 10:54 PM, Troy A. Griffitts wrote:
Dear Tobias,
Yes, our StrongsGreek and StrongsHebrew modules need work. I know the
Xiphos repo has improved Strongs modules. I was actually surprised to
see that our Strongs modules are still not using any SourceType entry
in the .conf file. They should be updated to use TEI, as this is what
we decided to use for lexicon markup, but I guess never updated our
modules.
Regarding your use case. In SWORD, the common way for parsing out and
making available useful information which might be found in a module
entry is the EntryAttributes mechanism. This would allow requests like:
module.getEntryAttributes()["Word"]["Transcription"]["Main"];
module.getEntryAttributes()["Word"]["Transcription"]["Phonetic"];
module.getEntryAttributes()["Definition"]["Body"]["Text"];
module.getEntryAttributes()["Reference"]["000"]["Text"];
module.getEntryAttributes()["Reference"]["000"]["EntryKey"];
module.getEntryAttributes()["Reference"]["001"]["Text"];
module.getEntryAttributes()["Reference"]["001"]["EntryKey"];
If you haven't used EntryAttributes in SWORD yet, have a look at
something like the KJV with the tool: sword/examples/cmdline/lookup.
This utility prints out all the entry attributes associated with an
entry (among other things).
You may have noticed, above, one quirk with SWORD Entry Attributes in
that they are always referenced by a 3 level key. Searches are done
using / notation with empty segments and trailing '.' designating
wildcards, e.g., Word//Lemma./G1234/. This would find any entry in the
KJV with an EntryAttribute having strongs G1234 in the "Lemma.*"
entries for any Word number.
So, to implement what you want, I would suggest we update our
StrongsGreek and StrongsHebrew with markup and use info from a source
we know we can designate the copyright information (this is my concern
from other lexicon data out there). We could talk with Tyndale about
the pedigree of their data for their Greek and Hebrew Strong
definitions and possibly finalize a module we could share, or improve
on ours with data from various sources we can cite, like
http://crosswire.org/svn/sword-tools/trunk/flashtools/ for adding
"RealGreek" and "RealHebrew" word headings to our current lexica.
What we should really start with is a TEI markup of our current
lexica, if we decide to improve our current modules.
THEN, with markup in place, parsing the entries into entry attributes
would be really simple by adding a filter... in fact, looking for an
example, I strangely found:
http://crosswire.org/svn/sword/trunk/src/modules/filters/greeklexattribs.cpp
I wonder if we use this filter on any module, currently...
Troy
On 11/9/19 3:31 AM, Tobias Klein wrote:
Hi,
I'm currently working on Strong's support for Ezra Project.
I've been implementing a Strong's parsing functionality that enables
flexible formatting of the Strong's definitions (from StrongsGreek
and StrongsHebrew) in my frontend.
Without this functionality the frontend would have to "dump" the
definition of a Strong's key and it wouldn't have freedom in how the
definition is formatted / layed out.
Having this functionality available, the frontend can work with
individual parts of the Strong's definition and apply specific
formatting and layout.
The parsing divides a Strong's entry into:
- Transcription
- Phonetic transcription
- Definition
- List of references
In case of Ezra Project the formatting looks like this now:
https://raw.githubusercontent.com/tobias-klein/ezra-project/master/screenshots/strongs_formatting_example.png
I'm pasting the definition of my StrongsEntry class below, which is
the base for this implementation (see
https://github.com/tobias-klein/node-sword-interface/blob/master/src/strongs_entry.hpp):
classStrongsEntry
{
public:
StrongsEntry(std::stringkey, std::stringrawEntry);
virtual~StrongsEntry(){}
staticStrongsEntry*getStrongsEntry(sword::SWModule*module,
std::stringkey);
std::string rawEntry;
std::string key;
std::string transcription;
std::string phoneticTranscription;
std::string definition;
std::vector references;
private:
voidparseFromRawEntry(std::stringrawEntry);
voidparseFirstLine(std::stringfirstLine);
voideraseEmptyLines(std::vector);
voidparseDefinitionAndReferences(std::vector);
};
Now I'm wondering whether something like this could actually be
useful as part of the Sword engine, since the use case of "flexible
Strong's formatting" may also be relevant for other frontends.
Best regards,
Tobias
___
sword-devel mailing list:sword-devel@crosswire.org
Re: [sword-devel] Parsing Strong's to support more flexible layout in user interface
Dear Tobias,
Yes, our StrongsGreek and StrongsHebrew modules need work. I know the
Xiphos repo has improved Strongs modules. I was actually surprised to
see that our Strongs modules are still not using any SourceType entry in
the .conf file. They should be updated to use TEI, as this is what we
decided to use for lexicon markup, but I guess never updated our modules.
Regarding your use case. In SWORD, the common way for parsing out and
making available useful information which might be found in a module
entry is the EntryAttributes mechanism. This would allow requests like:
module.getEntryAttributes()["Word"]["Transcription"]["Main"];
module.getEntryAttributes()["Word"]["Transcription"]["Phonetic"];
module.getEntryAttributes()["Definition"]["Body"]["Text"];
module.getEntryAttributes()["Reference"]["000"]["Text"];
module.getEntryAttributes()["Reference"]["000"]["EntryKey"];
module.getEntryAttributes()["Reference"]["001"]["Text"];
module.getEntryAttributes()["Reference"]["001"]["EntryKey"];
If you haven't used EntryAttributes in SWORD yet, have a look at
something like the KJV with the tool: sword/examples/cmdline/lookup.
This utility prints out all the entry attributes associated with an
entry (among other things).
You may have noticed, above, one quirk with SWORD Entry Attributes in
that they are always referenced by a 3 level key. Searches are done
using / notation with empty segments and trailing '.' designating
wildcards, e.g., Word//Lemma./G1234/. This would find any entry in the
KJV with an EntryAttribute having strongs G1234 in the "Lemma.*" entries
for any Word number.
So, to implement what you want, I would suggest we update our
StrongsGreek and StrongsHebrew with markup and use info from a source we
know we can designate the copyright information (this is my concern from
other lexicon data out there). We could talk with Tyndale about the
pedigree of their data for their Greek and Hebrew Strong definitions and
possibly finalize a module we could share, or improve on ours with data
from various sources we can cite, like
http://crosswire.org/svn/sword-tools/trunk/flashtools/ for adding
"RealGreek" and "RealHebrew" word headings to our current lexica.
What we should really start with is a TEI markup of our current lexica,
if we decide to improve our current modules.
THEN, with markup in place, parsing the entries into entry attributes
would be really simple by adding a filter... in fact, looking for an
example, I strangely found:
http://crosswire.org/svn/sword/trunk/src/modules/filters/greeklexattribs.cpp
I wonder if we use this filter on any module, currently...
Troy
On 11/9/19 3:31 AM, Tobias Klein wrote:
>
> Hi,
>
> I'm currently working on Strong's support for Ezra Project.
>
> I've been implementing a Strong's parsing functionality that enables
> flexible formatting of the Strong's definitions (from StrongsGreek and
> StrongsHebrew) in my frontend.
> Without this functionality the frontend would have to "dump" the
> definition of a Strong's key and it wouldn't have freedom in how the
> definition is formatted / layed out.
> Having this functionality available, the frontend can work with
> individual parts of the Strong's definition and apply specific
> formatting and layout.
> The parsing divides a Strong's entry into:
> - Transcription
> - Phonetic transcription
> - Definition
> - List of references
>
> In case of Ezra Project the formatting looks like this now:
> https://raw.githubusercontent.com/tobias-klein/ezra-project/master/screenshots/strongs_formatting_example.png
>
> I'm pasting the definition of my StrongsEntry class below, which is
> the base for this implementation (see
> https://github.com/tobias-klein/node-sword-interface/blob/master/src/strongs_entry.hpp):
>
> class StrongsEntry
> {
> public:
> StrongsEntry(std::string key, std::string rawEntry);
> virtual ~StrongsEntry(){}
> static StrongsEntry* getStrongsEntry(sword::SWModule* module, std::string
> key);
> std::string rawEntry;
> std::string key;
> std::string transcription;
> std::string phoneticTranscription;
> std::string definition;
> std::vector references;
> private:
> void parseFromRawEntry(std::string rawEntry);
> void parseFirstLine(std::string firstLine);
> void eraseEmptyLines(std::vector& lines);
> void parseDefinitionAndReferences(std::vector& lines);
> };
>
> Now I'm wondering whether something like this could actually be useful
> as part of the Sword engine, since the use case of "flexible Strong's
> formatting" may also be relevant for other frontends.
>
> Best regards,
> Tobias
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
[sword-devel] Parsing Strong's to support more flexible layout in user interface
Hi,
I'm currently working on Strong's support for Ezra Project.
I've been implementing a Strong's parsing functionality that enables
flexible formatting of the Strong's definitions (from StrongsGreek and
StrongsHebrew) in my frontend.
Without this functionality the frontend would have to "dump" the
definition of a Strong's key and it wouldn't have freedom in how the
definition is formatted / layed out.
Having this functionality available, the frontend can work with
individual parts of the Strong's definition and apply specific
formatting and layout.
The parsing divides a Strong's entry into:
- Transcription
- Phonetic transcription
- Definition
- List of references
In case of Ezra Project the formatting looks like this now:
https://raw.githubusercontent.com/tobias-klein/ezra-project/master/screenshots/strongs_formatting_example.png
I'm pasting the definition of my StrongsEntry class below, which is the
base for this implementation (see
https://github.com/tobias-klein/node-sword-interface/blob/master/src/strongs_entry.hpp):
classStrongsEntry
{
public:
StrongsEntry(std::stringkey, std::stringrawEntry);
virtual~StrongsEntry(){}
staticStrongsEntry*getStrongsEntry(sword::SWModule*module, std::stringkey);
std::string rawEntry;
std::string key;
std::string transcription;
std::string phoneticTranscription;
std::string definition;
std::vector references;
private:
voidparseFromRawEntry(std::stringrawEntry);
voidparseFirstLine(std::stringfirstLine);
voideraseEmptyLines(std::vector);
voidparseDefinitionAndReferences(std::vector);
};
Now I'm wondering whether something like this could actually be useful
as part of the Sword engine, since the use case of "flexible Strong's
formatting" may also be relevant for other frontends.
Best regards,
Tobias
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
