gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz] Structure proposal: RDF (+Xu)


From: Alatalo Toni
Subject: Re: [Gzz] Structure proposal: RDF (+Xu)
Date: Wed, 19 Feb 2003 09:14:25 +0200 (EET)

On Tue, 18 Feb 2003, Alatalo Toni wrote:

> we have now had two proposals, the quick thoughts from Tuomas and the,
> quite thorough, analysis from Benja. i've read them a couple of times,

of course, with better reading many things became clearer - so i'm happy
to see that there has not been any responses to the hastyness from
yesterday, yet, and try to correct my own mistakes first: :)

> haven't seen conflicts/differences really - but not heard comments from

Benja's proposal does note on several occasions requirements from
Tuomas, at least on the constraints (consistency rules).

> - is what Tuomas suggests  simpler, lower level (tuples)?
> - RDF is more complex, higher level? or just more specified, at this point?

this was quite rubbish: the actual proposal from Tuomas is about
/associative mappings/ between points, and the example seems like a triple
to me (GUID-(contains)-enfilade). so it's very similar to RDF?

now, hopefully to the actual matter. i mostly comment Benja's proposal,
but would definitely like (need) to hear more about what Tuomas wrote
(there probably are a lot of peculiarities and potential issues that I
don't see from the dense outline -- oh and the splitting-the-project -part
i could comment separately but basically it seems like a good idea).

1. catering for Xu content: why 'should probably define a type of literal'?
   there may well be good reasons for this, i just don't immediately see..,
   would've assumed typed URI(ref)s, but haven't thought this through.
   (otherwise 've been thinking about the problems in Xu'ing e.g. Zope).
   or did you just mean something typed, be it literal or URIref?
   that part is clear, i guess. and not insisting on it i may well agree.

2. was the problem/fact that the notes in (g)zz have tended to become
   trees a problems with zzstructure, or only with the views that did
   not really support working n-dimensionally, i.e. typing the links?
   when i started taking notes, i first did not make trees at all but
   a total mess (in d.an and d.org that had slight meanings, mostly
   just the fact that they together are an.org :) . then i was working
   for some time making trees (d.1&2), also made horizontal links between
   branches i guess .. would like to see your pattern for it, but anyhow
   disliked the fact that zzstructure was underused there all the time.
   in any case, agree that m:n linking would be useful. would be
   interesting to hear zz's counterarguments for that, though, if there
   are any (m:n can of course be built with zzstructure as has been done?)
   also about zz, i should probably get familiar with the cursor problem,
   .. a search in the archives of this list might do, but pointers are
   welcome :)

3. about the 'knowledge about things to be shown', i.e. that 'e.g. for
   people we usually show their name' -thing in the 1. basic view.
   seems good, was first wondering where those rules are / that
   information is, but that became clearer in the following paragraph with
   the simple setting. actually just now got more insight in the idea
   about about ordering -- did i understand correctly: for e.g. a
   person there may be a number of properties, e.g. name and address etc.,
   and when e.g. a new one is created, they are opened to be edited in
   that order? or would it be the way i first understood, that for a
   person you would always edit the name .. hm the text actually seems to
   say this, but perhaps the misunderstanding that just occurred might
   work sometimes, too :o

4. was happy to see the note on views for specific, but applitude
   independent, structures. missed e.g. tables with 0.6.

5. haven't bought the left->right yet, but will check the arguments from
   xupdf.

6. looking forward to the upcoming separate writeup on 'semantic
   spreadsheet' :)

should we split this thread into structure and views etc., or should they
be discussed together?

cheers,
~Toni





reply via email to

[Prev in Thread] Current Thread [Next in Thread]