[okfn-discuss] Re: Marginalia

[Rufus Pollock]

Geoffrey Glass wrote:
> Hello Rufus,
>> Yes I'd thought that there might be a problem with one long pre and 
>> had already prepared line numbered versions -- just set format to 
>> lineno as in:
>>
>> http://demo.openshakespeare.org/view?name=hamlet_gut&format=lineno
 >
> That will work fine (what a lot of IDs!).  BTW, there's an obscure part 
> of the HTML spec that says IDs have to start with a letter.  It's so 
> obscure I don't think it makes any practical difference, though I have 
> been tempted to use that to distinguish terms in Marginalia paths.
 >

Thanks for the tip -- I'll change the ID generation algorithm.

>>> between the start of the document and a highlighted passage, 
>>> Marginalia just fires off an XPath expression to grab the line and 
>>> counts from there.  (IE rears its ugly head here -  I don't think it 
>>> supports XPath, so Marginalia has to count lines instead.  See 
>>> PathToNode in marginalia.js).
>> Is this a change from your previous version? I thought the old version 
>> used your own custom range object with offsets in words from the start 
>> of an entry (with an entry designated by special markup inside the 
>> source document)
 >
> Yes.  This is where the performance improvement comes from.  Rather than 
> counting words all the way to your highlighted text, it follows a simple 
> XPointer (e.g. /4/5/9) to the start of first preceding block-level 
> element, *then* starts counting words.  (Unlike in XPointer, the 
> highlighted text may or may not actually be within the referenced 
> element, however - this is necessary for ordering.)  I've added a 
> summary of this to my technical page.
> 
> http://www.geof.net/code/annotation/technical

I've read that page but still have a couple of questions:

1. Do I still need special div with css classes in my source document 
for marginalia to work (as I did in the previous version)

2. Can I have ranges that extend across blocks (i.e. that start in one 
xpointer reference and end in another)

[snip]

>>> Absolutely!  :)  My use of Atom is rather clumsy.  I really don't 
>>> think it's appropriate for me to overload the semantics of title, 
>>> summary, etc. as I do;  it might make more sense to embed the 
>>> information as a microformat in an entry's content.  But that might 
>>> make parsing much harder (especially when the content section is 
>>> escaped with &s everywhere).  For now I'm ignoring the issue.
>>
>> On the contrary I thought your overloading approach was an excellent 
>> idea. Among other things it makes it possible (I think) for the 
>> annotation stream to get pulled in the same way as the blog post stream.
> Well thanks :)  It's just not obvious to me that the title would be the 
> annotation note, the summary the quote, etc.  A perfectly reasonable 
> person could reverse the roles (it might be I've misremembered here and 
> done that myself).  It might also be useful to use some algorithm to 
> derive even better title and summary values, with the information needed 
> by Marginalia in the HTML content.

Sure, it's not entirely clear what the assignment should be but I think 
one definitely be using those attributes in some manner. I will take a 
better look at the hAtom microformat.

> It has recently occurred to me this could be used as a model for 
> annotating annotations (since both the annotated document and the 
> annotation stream could both be represented using the hAtom microformat).

Exactly, which would be rather neat ...

Regards,

Rufus