Re: [Gzz] PEG: vocabprocess -- cleanup and freeze RDF vocabularies

[Tuomas Lukka]

Thank you for the comments, have put in fixes for some,
one open issue, one issue with suggested resolution, unless
you argue well for changing it.

On Sun, May 11, 2003 at 09:46:54PM +0300, Matti Katila wrote:
> On Sun, 11 May 2003, Tuomas Lukka wrote:
> > =============================================================
> > PEG vocabprocess--tjl: process for RDF vocabularies
> > =============================================================
> > It seems that vocabularies are easy to create but difficult
> > to define and maintain. We need more process for vocabularies
> > which will be put into actual public use.
> 
> I think none of our vocabularies are currently public.

Yes, but we do want to publish fenpdf ASAP.

> > This PEG changes the current fenfire vocabulary quite a bit,
> > moves a lot of stuff into lava.
> 
> So, there's 6 classes and you talk about lot of stuff?

Yes, there's 6 classes and somehow, because it's so messy,
they do to me give the appearance of there being really lots of stuff.

It is funny.

> > Issues
> > ======
> > 
> > - What about ALPH? How much should we be defining ALPH things
> >   here, outside Alph proper?
> 
> Yes, it was my fault even create it. It was too late at night to code 
> that.

Hey, no problem. After this, things like that end in lava, they're
easier to edit.

> > Create new package, ``org.fenfire.vocab.lava``.
> 
> If you want. I don't see this as an issue. We are not using the rdf as rdf 
> people think it should be used so what we win? 

*We* win in that it becomes extremely clear which parts of our vocabularies
we expect to remain stable eternally and which are still in an experimental
stage.

> > Vocabularies
> > ------------
> > 
> > ALPH
> > """"
> 
>  [...]
>  
> > Then, we have left ``xuLinkFrom``, ``xuLinkTo``, ``xuLinkType``.
> > We should probably avoid 'xu' in the permanent names,
> > just in case. These should be moved to FF.cLink, FF.cLinkFrom,
> > FF.cLinkTo for clink, "content link", a term Ted at some point used.
> 
> FF.CLink if you are going to use it as a rdf type.

Fixed

> > FF
> > ""
> > Retain.
> 
> There's no javadoc ;)

A part of this PEG is that it *will* be made.

> > PAPER, SPATIAL
> > """"""""""""""
> > 
> > Combine to one class, CANVAS2D.
> > Rename ``Canvas`` to ``Canvas2D``.
> 
> Why? What's the reason?
> I accept renaming paper to canvas2d but i don't see any reason to rename 
> spatial to canvas2d.

Can you give me an example where spatial would be used without canvas2d?
The point is, the x and y coordinates are pretty specific to canvases,
and while I see containment + x + y as a reasonable structure orthogonal
to everything else, separating containnment and x and y to me 
does not make sense.

Also, if it's spatial, it should also have z ;)

Of course, this is arguable, and if you come up with a good reason
why it should remain separate, we can do that too.

> > Rename coordX, coordY to X, Y.
> 
> If they are used as properties they should be x and y.

Fixed

> > PP
> > ""
> > Remove everything except association.
> 
> Grhmm..  Why we even have pp in our public vocabularies?
> By continuing your proposal of combining paper and spatial I suggest you 
> also join pp to canvas2d ;)

No, PP links do not have anything to do with spatial canvases. This is
a place where we do have the orthogonality between structures.

If we want to join it somewhere, it would be as a directed, untyped link
in FF. 

        Tuomas