Re: [Gzz] PEG: vocab again

[Tuomas Lukka]

On Mon, May 12, 2003 at 03:09:33PM +0200, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> >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.
> 
> When and how would conversion be done? When would it be unnecessary, 
> and why? This is the issue here.

In the scenario above it would be unnecessary; when real code starts
hitting the tree, the PEG has already been made.

We could define "no code in the default code paths of a
stable release shall use EXPERIMENTAL URIs",
would that satisfy you?

The people using devel stuff can take care of converting.

As to how, there are several options.

> >>>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.
> 
> Where?

        PP links (now dLinks) or xu links (now CLinks)

This defines "dLink == PP link, CLink = xu link".

> >>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?
> 
> I think there can be more descriptive names, so yes, I think I oppose 
> it. But as I said, I think this should be an own PEG and thread of 
> discussion.

Ok, will do.

> >>- Data type of the literal?
> >
> >Says "an enfilade parseable by alph". Need more?
> 
> That's not a datatype-- alph doesn't know datatypes, it could even 
> parse a (malformed) int-datatype literal that contains the XML 
> serialization of an enfilade.
> 
> The old version of RDF distinguished string and XML literals; the new 
> version, which has been in last call, will have an optional datatype 
> URI associated with each literal, and one of these URIs will signify 
> XML literals. See the specs at w3.org.

Ok, what do you suggest?

> >>- 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?
> 
> String, I think.

Why? What is it needed for?

        Tuomas