Cursor semantics (was Re: Cursors in RDF (was Re: [Gzz] Structure proposal: RDF (+Xu)))

[Benja Fallenstein]

Benja Fallenstein wrote:
> Benja Fallenstein wrote:
> > Benja Fallenstein wrote:

[Warning: I'm going to continue talking to myself until somebody else 
joins in :-)]

> > > There's a cursor position, the focused node, shown in the middle of 
> > > the screen. [...]
> > > In addition to the focus, we keep a selected node. This is shown 
> > > directly right of the focused note (if connected poswards) or 
> > > directly left (if connected negwards).
> >
> > Just noted that literals make this a little more complicated. We want 
> > to be able to focus literal nodes, yet we cannot make a link to them, 
> > because they're without identity. From the semantics perspective, this 
> > makes sense, but for editing, it makes things yet a little more 
> > difficult.
> >
> > Have to think about this. Possibly saying "the 'age' property literal 
> > of person X is accursed" would be right, but there may be two such 
> > literals... hmmmm.
>
> Maybe you shouldn't be able to *accurse* literals anyway, only select 
> them on the wheel.

[...]

> However, we still need a way to select the literal as the current 
> 'rotation' of the wheel. If we just stored the literal itself, it would 
> be possible that there are two different properties on an object with an 
> equal literal value... so we'd probably need to store the property as 
> well...

Just noted something important to realize here-- considering how RDF is 
about semantics. Question: What kind of thing do our cursors accurse? 
Answer: RDF nodes. They don't really accurse the XMMS media player, or 
the W3C home page, or the string "Africa"; they accurse the RDF node 
that represents the media player or home page, or the RDF literal whose 
value is "Africa."

But when we make a link to a RDF node, this is interpreted as saying 
something about the thing the RDF node represents, NOT saying something 
about the node itself. To get the semantics right, we need reification: 
to represent X, we create another node Y, with the property "Y 
represents-the-node-that-represents X" or something like that.

So our window could have a property accursesNode, and the value of that 
property would be the *reification* of the node the window accurses. 
This seems to make sense from a semantic POV. (It would be a little less 
direct, but not much so-- two arcs instead of one for a structure users 
rarely view directly.)

And if we did this, literals would become much easier: Literal nodes 
would also have a reification, something like "The literal node 
containing string S which is the value of property P of node N."

Example 1:

window accursesNode X
X instanceOf URINodeReification
X representsTheNodeThatRepresents http://w3c.org

Example 2:

window accursesNode Y
Y instanceOf LiteralReification
Y isString "World Wide Web Consortium"
Y isValueOfProperty hasAuthor
Y isValueOfSubject http://w3c.org

I.e., in the latter case, the literal node containing the author name of 
w3c.org would be accursed.

We'd need a third class for reifying blank nodes... But all this seems 
to make a lot more sense right now, at least to me :-)

-b.