gzz-dev
[Top][All Lists]
Advanced

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

Re: [Gzz] PEG: vocab again


From: Tuomas Lukka
Subject: Re: [Gzz] PEG: vocab again
Date: Mon, 12 May 2003 15:55:19 +0300
User-agent: Mutt/1.4.1i

On Mon, May 12, 2003 at 01:51:38PM +0200, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> >- Is it ok to have a separate namespace for experimental things?
> >
> >    RESOLVED: Yes, conversion can be automated / done with inference.
> >    Any URI in the experimental space should not be widely used
> >    before being properly defined and accepted.
> >
> >    It is desirable to be able to *see* from the URI which data is
> >    stable, which is not, without having to look at the definitions.
> >
> >    For example, grepping for the experimental ns from a file would
> >    give you a good idea whether your data is based on stable code.
> >
> >    The idea is also that conversion wouldn't be too often necessary:
> >    the move from lava to real wouldn't require too much work, just a 
> >    PEG
> >    round.
> 
> Please explain how you think a typical situation would work. When 
> would the vocab be pegged? Why wouldn't conversion be necessary?

Ok, let's take the RST canvas as an example. Mudyc puts in his sketches
in the vocab file and tries things. Once things start working well enough
to start thinking of integrating it into fenfire proper, he PEGs the
vocabulary.

The data model can be defined and finalized before the code that uses it.

Do you want clarifs in the PEG?


> >- Should we merge spatial into canvas2d?
> >
> >    RESOLVED: Yes. Can you give me an example where spatial would
> >    be used without canvas2d?
> 
> I don't think RESOLVED should have rethorical questions, it looks bad. 
> :-) I think the point is that it sounds a bit like an accusation 
> ("c'mon, your question doesn't make sense") which seems really bad for 
> RESOLVED :-)

True, that was cut&paste from the email. Fixed.

> >    It would be acceptable to have Spatial be a *superclass* of 
> >    Canvas2D, but this might not be worth the trouble.
> 
> I think superclasses of vocab classes is not good...

For most purposes, agreed.

> >For instance, a spatial canvas is a reasonable unit: there is a 
> >canvas, it contains
> >certain nodes at certain locations. However, the PP links (now 
> >dLinks) or xu links (now CLinks)
> >between different canvases do not actually belong in the same place; 
> >they are orthogonal
> >to the spatial structure.
> 
> Could you please not make references to 'dLinks' and 'CLinks' before 
> defining them? I feel like you're assuming I know something that I 
> can't know yet.

I did state the earlier concepts that were renamed - this actually
does define them.

> I think the PP link / xu link / dLink / CLink renaming&philosophy 
> stuff also deserves an own PEG which should be resolved before 
> finalizing these vocabularies.

Do you oppose the name change?

> >The more independent we can make the codes, the easier it will be to 
> >slot in new
> >behaviours.
> 
> "The codes" = ?

Fixed

> >Change the prefix ``http://fenfire.org/vocabulary/``
> >to ``http://fenfire.org/rdf-v/``.
> >After the prefix, each namespace shall contain the year and month it 
> >was originally
> >defined in, in the form
> >``2003/05/``. After that, the name of the namespace, lowercase, with 
> >.html -suffix.
> >So, for instance, FF.content would be
> >``http://fenfire.org/rdf-v/2003/05/fenfire.html#content``.
> 
> This doesn't specify the '#', but uses it in the example. Please be 
> clear in the spec.

Done.

> Issue: Why ".html"? It serves zero purpose (except allowing the 
> website admin to be lazy) and makes it unintuitive to serve non-HTML 
> representations of the namespace (such as RDF Schema).

This was the original way the vocabs were defined. I'm happy to remove it.
Fixed.

> >All new words define without PEG go into org.fenfire.vocab.lava
> >and use the prefix ``http://fenfire.org/EXPERIMENTAL/rdf-v``, after 
> >which the URI continues as above.
> >
> >All entries in vocabulary classes shall have their **official**
> >definitions there, in their javadocs. There shall be no members
> >or classes without good documentation.
> 
> Not clear whether this refers to ff.vocab.lava, ff.vocab, or both.

Fixed. Mandatory for vocab, strongly recommended for lava.

> >ALPH
> >""""
> >
> >Remove ``content``, is in FF.
> >
> >Remove ``clone`` and ``cloneType`` and ``dataType``, 
> >not current/relevant.
> >
> >Remove ``xuType``, should be ``xuLinkType``.
> >
> >Then, we have left ``xuLinkFrom``, ``xuLinkTo``, ``xuLinkType``.
> >We should probably avoid 'xu' in the permanent names,
> >just in case. These should be moved to CLINK.CLink, CLINK.cLinkFrom,
> >CLINK.cLinkTo for clink, "content link", a term Ted at some point 
> >used.
> 
> Do say that you define CLINK below.

Fixed

> >FF
> >""
> >
> >Retain. Javadocs::
> >
> >    /** RDF Vocabulary of central concepts of Fenfire.
> >     */
> >    public class FF {
> >     /** A property signifying fluid media "content" of a node.
> >      * Used as  (node, FF.content, literal) where the literal is
> >      * an enfilade
> >      * parseable by alph.
> >      * This is analogous to spreadsheet or zzStructure cell 
> >      contents.
> >      */
> >     static public Object content;
> >    }
> 
> - Data type of the literal?

Says "an enfilade parseable by alph". Need more?

> - It should be clear from this what the URIs of the terms are. Giving 
> the namespace URI would suffice.

Do you want it in the javadoc or is a String inside FF sufficient?


> >CLINK
> >"""""
> >
> >A new namespace for Xanalogical content links.
> >Javadoc::
> >
> >    /** RDF Vocabulary of content links.
> >     */
> >    public class FF {
> >     /** The RDF type for content links. An node which is a content 
> >     link
> >      * must have both the cLinkFrom and cLinkTo properties.
> >      */
> >     static public Object CLink;
> 
> Objects of rdf:type statements are called classes.

Fixed

> >     /** The Alph-parseable enfilade literal of a content link 
> >     from-end.
> >      */
> >     static public Object cLinkFrom
> >     /** The Alph-parseable enfilade literal of a content link 
> >     to-end.
> >      */
> >     static public Object cLinkTo;
> 
> What are the data types of these literals?

See above. 

> >    public class CANVAS2D {
> >     /** The RDF type of spatial 2D canvases.
> >      * Canvases contain (with the "contains" property
> >      * nodes, which shall have the "x" and "y" properties.
> >      */
> 
> Syntax error: Unbalanced paranthesis.

Fixed

> >     /** The x and y coordinates of a node on a canvas.
> >      * (node, x, literal), where the literal is parseable
> >      * as a float. 
> 
> Is that "0.7" or "0.7f"?

0.7.

Fixed.

> >Remove everything except association. Move association to DLINK.
> >Remove class.
> 
> "Remove this class"
> 
> >     /** The RDF type attribute. A node's type can be declared to be 
> >     Foo * by a triple * (node, RDF.type, Foo).
> >      */
> 
> What does the asterisk mean?

Bad linebreaking ;)

        Tuomas




reply via email to

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