Syntax Searching Suggestion
I know it's a little late now since the release is "coming soon," but I thought I'd make the suggestion anyway.
It would be helpful if we could either right click on a phrase node in the trees themselves and select a link like:
"Copy to Syntax Search"
Or something like that, where then we could edit out details of the particular structure until we have the search structure we want for finding syntactically similar clauses & phrases.
Comments
-
Mike,
Wow...that would be a huge time saver...!
I'm all for that.
Robert Pavich
For help go to the Wiki: http://wiki.logos.com/Table_of_Contents__
0 -
Sounds good!
I'd like to be able to add additional constructs to a page/worksheet as per Graphical Query, so that we can implement complex OR's. I don't want 4 pages when it is done with one page in v3.
Dave
===Windows 11 & Android 13
0 -
I wholeheartedly agree with both Mike and Dave's suggestions!
0 -
I know it's a little late now since the release is "coming soon," but I thought I'd make the suggestion anyway.
It would be helpful if we could either right click on a phrase node in the trees themselves and select a link like:
"Copy to Syntax Search"
Or something like that, where then we could edit out details of the particular structure until we have the search structure we want for finding syntactically similar clauses & phrases.
Hi Mike
This is a great suggestion and is a conversation we've been having internally since before we released the first implementation of syntax searching in LDLS3.
It is not the easiest of tasks, though, and my understanding is that we haven't had resources to devote to it.
One question in thinking about this: How much to copy? The whole highlighted structure, with all node-level information for every node? So word nodes would have all properties (text, lemma, morph, gloss, louw-nida, etc.) Or none of it, just the structure (that can even be problematic)?
This is the first tough question, there are others. I'm not trying to brush off the suggestion; I'd rather try to figure out what folks mean/expect when copying a node to a search editor.
So, what should be copied in this context?
Rick Brannan
Data Wrangler, Faithlife
My books in print0 -
Even though I'm not Mike, I'll venture to answer.
Copy everything from the node selected onward. So if I select a clause and click "copy to syntax search," everything in that clause (including all the properties of each node) should be copied. If I click on a word group, then everything from that wordgroup onward should be copied, etc. Then, as Mike mentioned, we can add or remove criteria to the copied search as we see fit.
I'd be content with just the structure, but more would be better.
0 -
Yeah, I had a feeling this would be the question -- and I was already been thinking about it when first wrote the post.
One question in thinking about this: How much to copy? The whole highlighted structure, with all node-level information for every node? So word nodes would have all properties (text, lemma, morph, gloss, louw-nida, etc.) Or none of it, just the structure (that can even be problematic)?
So here is my suggestion. I'm doing this backwards and trying to prioritize things with some reasoning behind my thoughts (that means that each of the items in the individual lists are ranked in priority in a "meta-list" across the board.
Things that don't need be copied:
- Glosses.
These are most definitely the lowest priority and are the least relevant to the Greek text & the purpose of syntax searching. - Text.
While at time, I'm sure people have found this helpful, I have never used used it. Whenever I actually get to the word level in my searches, I'm either interested in only the lemma and where the lemma occurs in syntactic structure X OR I'm looking for particular morphology independent of the lemma. I can't say I've ever been interested in the inflectional form of a specific lemma -- though I would be interested in whether I'm a minority on that or not and would be interested if other syntax searches would chime in on this one.
Things that probably don't need to be copied:
- L&N#'s.
I was so close to putting this one in the list above, but then I remembered that in L4, it is possible to search through subdomains -- which is awesome; Rick, you've done great work here. In L3, I rarely used L&N#'s because the full domains were often way too broad too be terribly useful, unless you were specifically looking for something like "proper names" which actually made L&N rather nice. - Lemma (?).
Just like I almost put L&N#'s in the list above, I almost post Lemma's in the the list below. On the one hand, I will admit to have done plenty of searches using the lemma, not as many as I have with morphology, but still a good number. But also, typically when I've used Lemma's in searches, I've been doing it to circumvent the fact that in L3, I couldn't use L&N subdomains, so both of these in this list pull me in both directions. In any case, Lemma's would be a lower priority for me. Besides, typing in the lemma is both easier and faster than typing/choosing morphology or L&N#'s.
Things that probably should be copied:
- Morphology.
Of the word level grammatical information, morphology is definitely what I use the most and I'm typically interested in morph info in the majority of the time. The main reason it isn't in the four category of "Things that should be copied" is that I would probably view removing it as more of a hassle than adding it. That's pretty subjective, but, hey, what can I say...? From the perspective of the user, the effort of removing something like @VAAM2P would probably be viewed a greater waste of time than adding @N[AD]SM. - Other Node Level Information Above the Word Level.
Things like phrase types & grammatical relations (i.e. Opentext's Clause Categories & Cascadia's Clause Functions) should probably be copied. I would places these as a higher priority (as a user) for copying than Morphology simply because they generally more easily and faster removed since it's generally only one click per constituent.
Things that should be copied:
- The Highlighted Syntactic Structure.
Adding and deleting the nodes themselves is much faster & simpler in L4 than in L3 - particularly since you can now drag things around. That's awesome. Again, great work on this.
If I've missed anything, let me know and I'll give an opinion.
This is the first tough question, there are others. I'm not trying to brush off the suggestion; I'd rather try to figure out what folks mean/expect when copying a node to a search editor.
Yeah, I had a feeling that might be the case and I'm always willing to give feedback.
0 - Glosses.
-
Also, I'm going to have to take some time working through Cascadia before I could give my thoughts about the additions info in there that's not in Opentext. My access to Cascadia has been off and on through the testing and I'm not as familiar with it as I would like to be.I'm also not terribly familiar with the Hebrew databases or the Lexham Syntactic GNT, so I don't know what I could say about those.
So what's in my post above is more related to Opentext than Cascadia.
It'll probably be a couple weeks before I could give thoughts on things like:
Clause/Phrase Heads, Clause Types, Node Heads, etc.
Oh, and I should also mention that Agreement should not be copied, that should be added by the user, IMO. Could even be???
0 -
I'd like to be able to add additional constructs to a page/worksheet as per Graphical Query, so that we can implement complex OR's.
Dave, I don't know if this is new or not, but I just noticed that you can add OR's to the syntax fields.
0 -
Dave, I don't know if this is new or not, but I just noticed that you can add OR's to the syntax fields.
Ditto - from looking at the templates!
I'm still trying to digest the Gap search which I supplemented with an Unordered group and picked up both relevant and spurious results!
Dave
===Windows 11 & Android 13
0 -
I'm still trying to digest the Gap search which I supplemented with an Unordered group and picked up both relevant and spurious results!
Post a pic and let me know what you're trying to find. Maybe we can work it out.
0 -
Here's the basic search which produces 155 hits:-
Here's one variatiion of the gaps search to which I attached the Unordered group:-
The Predicator finishes with a word as per the first search. I get 175 results, which duplicates the 155 of the first search (why?) and has 20 results with 8 being unrelated/spurious, 8 being additional instances within the one verse and 4 being genuine "gaps" -> Matt 26:60, Acts 25:13, 2 Cor 5:20, 2 Pe 1:17.
The spurious ones are:
Matt 14:15; 19:10, Lk 9:51, Acts 1:21-22; 16:1, 1 Tim 6:4-5, Heb 10:8 & Rev 11:18.
Dave
===Windows 11 & Android 13
0 -
Dave,
Thanks! I have to get some work done for church tonight, but I'll try to take a look at it later today.
0 -
Dave,
I've looked at this a little bit and have the same problems you have. My hypothesis is that the problem comes from having the GAP operator in an unordered group (possibly because the GAP operator isn't actually a syntactical function). It just doesn't seem to work well there. I'm going to try that with some other searches later today and see if the results are consistently off. If so, I think the solution will be (which I'll test later as well) to never put a GAP operator in an unordered group, but rather to use the OR operator and construct two separate searches.
Like I said, I'm still just guessing at this point. Have you had any further luck?
0 -
Like I said, I'm still just guessing at this point. Have you had any further luck?
No opportunity to look at it. But you've given me some ideas...
Dave
===Windows 11 & Android 13
0 -
Dave,
The more I think and play around with searches, the more confident I'm becoming that they won't work properly in unordered searches. This must come in part from the fact that they (as Rick mentions here: http://community.logos.com/forums/p/3018/23107.aspx#23107) are not actual search elements. I took your genitive absolute search with the unordered gap, removed the gap and ran two searches, one with the Gap coming first, the other with it coming second. Between the two searches there are 3 results (Matt 26:60, Acts 25:13, and 2 Peter 1:17). All three of these are found when adding the unordered group back into the search. But why all the other hits? My guess is as follows:
- As mentioned above, the Gap operator does not actually "exist".
- Gap operators require the node coming out of them to have "matching skips levels" checked (why?)
- The result is that for some reason, that predicator coming out of the gap operator (in your gen absolute search), which demands for levels to be skipped, is understood incorrectly by the search.
- I think it also may have something to do with the fact that neither "anything" or "gap" are "real items." Connecting two "fake" items together may cause problems. This is more a hypothesis than anything else though - kind of a gut feeling.
So clearly I don't really understand the problem, but I do know the solution (at least for now) - no gap operators in unordered groups. Use an OR operator instead. [*-)] [:S]
0
