[Prev][Next][Index][Thread]
Re: Link subjects and targets
> From JCMA@ai.mit.edu Sun Oct 29 00:03 PDT 1995
>
> At 7:32 PM 10/28/95, Wayne C. Gramlich wrote:
>
> >
> > Spanning embedded annotation:
> > An annotation that is attached to contiguous span
> > within a target object/document (i.e. between two points.)
>
> Would "region" be better understood than "spanning"? Are we considering
> the case of 3D, or N-D volumes (i.e., N points)?
Spanning => Region is OK by me.
> If there are no objections, these definitions can be stuffed into
> our glossary:
>
> http://www.sunlabs.sun/people/wayne.gramlich/work/w3c/annote/glossary.html
>
> Even when I add the .com to the host name, my browser doesn't come up with a DNS resolution
> for this URL.
My fingers betrayed me; the correct location is:
http://www.sunlabs.com/people/wayne.gramlich/work/w3c.annote/glossary.html
^^^
|
+------- www.sunlabs.sun.com won't work.
[...]
> I don't really like the variable width syntax. I would rather keep it consistent by always using
> a triple (target relation annotation) and then providing the attachment as a subsyntax to
> either target or annotation. (This will be consistent with what the link group has in mind.)
>
> This triple approach keeps the semantically important information on the same level.
>
> It allows the location substructure to be hacked independently of the toplevel syntax,
> ergo, without breaking those parsers.
Good point, let's use triples:
(Target-URL, Target-Location, Annotation-URL)
[...]
> Thus, each specification of an attachment location is:
>
> Attachment :: (url | urn attachment-location)
>
> attachment-location:: (start | end | point-location | region-location)
[...]
> How far do you think you can get with byte offset and pattern? It would be great if
> it goes a very long way, but it could optimistic.
Byte offsets are probably not very realistic, since most documents
on the Web are mutable. The pattern strategy should go fairly
far with linear textual document types (e.g. text, HTML, etc.)
Non-textual document types (e.g. audio, video, images, VMRL, etc.)
will probably not work that well. Hence, the proposal for an
extensible location specification is a good one. When we get to
the annotation representation issues, it seems likely that an
extensible format will be adopted.
[...]
-Wayne