Re: why does intern care whether there's a '#' or not?]

On Tue, 2002-08-13 at 21:43, Tim Berners-Lee wrote:
> 
> On Monday, August 12, 2002, at 06:26 PM, Dan Connolly wrote:
> 
> > In llyn.py, why does the intern method
> > care whether there's a '#' or not in the URI?
> >
> 
> Just for convenience, and space-saving habits from 64kB days,
> foo#bar is interned a la ("#bar", intern ("foo").  This means
> that the things without hashes on can be found rapidly
> from the thing with a hash,

er.. you can do that via uripath.splitFrag().

I suppose it's O(n) to find the '#', but... yeah,
that has a definite 64kB days feel to it.

> and there is an object there
> of a class which can have retreival information hung off it.

Hmm... that smells like more fuzziness about whether
these are syntactic objects or things identified
by syntactic objects.

Hmm... is the "already read and parsed..." check
in log:semantics done on a per-context basis?
From one angle, it should be, but I guess we
can make up just about any specification we
like for log:semantics. Though the number
of properties that interact novelly with
{} and quantification make me nervous...

> For example, I use it when counting how many occurrences of
> each namespace are to be output, and I plan to use it
> when zooming though a query to check that all the schemata
> have been loaded, in "think usingschemas" mode.
> 
> > In thing.py, why does the Symbol class
> > not include stuff like <foo#bar>?
> >
> 
> becase i couldn't call them both Symbol.

?

> In fact, the mapping of the language structure to the
> software class hierarchy doesn't work well.
> For example, formuale and bnodes at the moment
> have identifies   (with #)

Well, why is that? Why make up URIs for bNodes
and formulas at all?

> and so while that
> identifier is arbitrary, there is sofware wise that in common
> between for example a Formula and a regular
> foo#bar symbol.
> 
> 
> 
> > I would think that contact:homePage
> > is a symbol.
> >
> 
> Yes it is a symbol.
> If yo like we could make a classs Symbol which is
> a superclass o0f the current Symbol and Frgament
> but nothing else.

Yes, and then let's get rid of the Fragment class
and disconnect all its subclasses.

> 
> > I'd like to talk more about who interns what.
> > I'm having a lot of trouble tracking down
> > bugs... well, actually, I'm having trouble
> > figuring out whether various things are bugs
> > or not; i.e. what the invariants are.
> >
> 
> Oh. Sounds we should have an online phone call about it.

Meanwhile, I implemented the parser/store interface
I had in mind.

First, all constant terms are shared by all stores:

  http://www.w3.org/2000/10/swap/ConstTerm.py
	(note the use of the doctest module
	http://www.python.org/doc/current/lib/module-doctest.html
	way cool.)

Then, sinks have mkVar() and newFormula() methods;
these are private to the sink. Formulas have
an add() method.

  http://www.w3.org/2000/10/swap/KIFSink.py

I found it simplified the sink considerably to
use a fmla.add(s, p, o) rather than
sink.makeStatement(c, p, s, o); the latter has
to deal with arbitrary changes of scope, when
in fact, scopes change in a very constrained way.

The yapps-based parser shows how they caller side
of the interface.

  http://www.w3.org/2000/10/swap/rdfn3.g

In fact, this grammar shows the distinction between
constant terms and expressions that depend on
scope quite clearly:

    rule term<<scp>>:
                expr<<scp>>     {{ return expr }}
              | name           {{ return name }}

oops; by that measure, string literals are names;
they don't depend on scope. Ah... that's consistent
with the way the RDF Core model theory is written,
now that I think about it.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Wednesday, 14 August 2002 00:07:39 UTC