[ 
https://issues.apache.org/jira/browse/JENA-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16326370#comment-16326370
 ] 

ASF GitHub Bot commented on JENA-1459:
--------------------------------------

Github user ajs6f commented on the issue:

    https://github.com/apache/jena/pull/339
  
    Relax-- it's not nearly as bad as all that. :grin: I often say that having 
to rebase PRs a lot is good-- it means the project is lively and the code is 
evolving.
    
    For me, the trick (as almost always with git) was to remember that you are 
making/managing/corralling _deltas_ (aka commits), not versions. A branch can 
be thought of as a chain of deltas that starts somewhere and ends with a 
specific commit. Rebasing means taking a chain of commits that ends one branch 
and swapping what comes before it to be another branch. So in this case, you 
would have swapped the prefix of your branch (which has all the commits in 
master _except_ those that were in #335) for master itself. You would have had 
to do exactly the same adjustments, but you would have ended up with a series 
of commits that appeared (from the POV of seeing how deltas add up to change) 
as though you had begun work after #335 merged, which makes for a cleaner 
public history. Of course your commits always keep their metadata, so we will 
always actually know when they occurred in clock time.


> add highlighting support to jena-text
> -------------------------------------
>
>                 Key: JENA-1459
>                 URL: https://issues.apache.org/jira/browse/JENA-1459
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: Jena, Text
>    Affects Versions: Jena 3.6.0
>            Reporter: Code Ferret
>            Assignee: Code Ferret
>            Priority: Major
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> This issue proposes an improvement to jena-text to include optional 
> highlighting of results via:
> {{org.apache.lucene.search.highlight.Highlighter}}
> and 
> {{org.apache.lucene.search.highlight.SimpleHTMLFormatter}}
> The improvement will add an optional input argument to {{TextQueryPF}} that 
> signals that highlighting should be performed on the Lucene search results; 
> optionally indicates the _start_ and _end_ char sequences of a highlighted 
> term; optionally indicates the maximum number of fragments to highlight; and 
> optionally indicates a fragment separator.
> The highlighted results are bound to the {{?literal}} output argument of  
> {{TextQueryPF}}.
> Inclusion of this improvement will introduce a simple extraction of the 
> _highlight_ option string and a single test for the presence of the option 
> string so that the inclusion of the improvement will be of minimal impact 
> when highlighting is not used. The _highlight_ option string is passed 
> directly to {{TextIndex.query(...)}} and so can be used from code other than 
> {{TextQueryPF}}.
> The simplest use of highlighting is like:
> {code}
> select ?s ?lit
> where {
>   (?s ?sc ?lit) text:query (skos:prefLabel "one" 100 "lang:en" "highlight:") .
> }
> {code}
> which will produce results such as:
> {code}
> "another ↦one↤ abc"@en
> {code}
> the right-arrow (\u21a6) and left-arrow (\u21a4) are the default _start_ and 
> _end_ highlighting character sequences. These are chosen to be very unlikely 
> to occur in literals. These can be changed easily via {{"s:"}} and {{"e:"}} 
> in the highlight options, for example:
> {code}
> select ?s ?lit
> where {
>   (?s ?sc ?lit) text:query (skos:prefLabel "one" 100 "lang:en" "highlight: 
> s:<em class='hilite'> | e:</em>") .
> {code}
> which will produce results such as:
> {code}
> "another <em class='hilite'>one</em> abc"@en
> {code}
> Coding of this improvement is complete and a PR can be issued if there is 
> agreement that this improvement should be included in jena-text.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to