[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] Structure proposal: RDF (+Xu)
From: |
Benja Fallenstein |
Subject: |
Re: [Gzz] Structure proposal: RDF (+Xu) |
Date: |
Wed, 19 Feb 2003 12:13:07 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 |
Alatalo Toni wrote:
- 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?
Structurally, it's a superset of RDF (in a similar way that RDF is a
superset of zzstructure). Of course, you can express everything in any
of the three. I would say it's harder to come up with 'fundamental' f+c
views for it.
Tuple spaces have classically been used for coordination of
multithreading; RDF, for semantic descriptions.
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.
We're talking not about singe spans, but enfilades (lists of spans).
(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?
Nope, I meant a literal which is some representation of an enfilade,
likely in XML.
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?
It's that the fundamental zzstructure views work well with trees, but
not very well with m:n links. You can make them, of course, but they
require relcells (empty cells/clones) for the m:n connections which
makes browsing annoying.
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.,
Yes.
and when e.g. a new one is created, they are opened to be edited in
that order?
No.
or would it be the way i first understood, that for a
person you would always edit the name ..
If you accurse the person. The properties are own 'nodes,' even if one
(the name) is usually shown as the caption of the person node. I.e., to
enter the age, you'd create a new node connected through the 'age'
property, and type the age into that.
When you accurse the person, you would see the age connected to it (as
long as you have that property selected for viewing).
4. was happy to see the note on views for specific, but applitude
independent, structures. missed e.g. tables with 0.6.
You had them through the row/col views...
should we split this thread into structure and views etc., or should they
be discussed together?
I think structures need to be discussed with their 'fundamental' views.
-b.