Re: Minus signs in N3 (again)

[ Hm.  The headers of the message I'm replying to [1] are strange.
Was it sent to www-archive and bcc'd www-rdf-interest?  ]

> > The current solution is mapping sequences of "-" and "_" into sequences of 
> "_"
> > by taking a contiguous sequence of - and _, replacing _ with 0 and - with 1
> ,
> > then adding a leading "1", taking what you have as a binary number,
> > subtracting 1 from the result, and then writing that many _ signs.

> But most damningly, the escape mechanism devised to address this issue is
> not only unwieldy and unfriendly, it is not even complete: how do you escape
> "a-to-_"? My guess is cwm would currently escape it as a__to___, which
> collides with the encoding of "a-to__". Not to mention the fact that many N3
> parsers don't seem to implement "identifier munging" at all (see
> http://infomesh.net/2002/n3qname.html).

I wouldn't argue this mapping was friendly or wieldy, but I'm not sure
you've proven it's incorrect: as I follow the algorithm, "-_" turns
into binary 10, prefix with 1 to get 110, subtract one to get five, so
we get "a__to_____".  As far I can tell, cwm doesn't actually
implement any mangling, though, and there's nothing in the test suite
for it.

> So here's hoping Tim is now ready to excise this wart from N3. If he were
> serious about banishing '-' from RDF IDs, he should have fought that battle
> a long time ago, back when RDF was being finalized. It would seem much too
> late for that now, so the sensible thing to do is just accept it, properly
> accommodate it, and move on.

Why can't it be banished as a "best practice" instead of formally?
Kind of like using identifiers like x0d457e059624dc933b1566c4fe5da in
a C: it's allowed; it's just a really bad idea.

Meanwhile, I think forcing people to be careful with whitespace around
operators is an iffy proposition in a modern formal language.

> And while we're at it, the same thing goes for '.'. I expect some will
> reflexively protest that the use of '.' as the statement terminator makes
> this problematic. They might have a leg to stand on if it weren't for the
> fact that '.' is already also permitted within numeric (rational) literals.

"." is also being used as an infix path operator now, which I think
foils your plan.

Of course, this forces people to use spaces after the "." which ends a
sentence and not to use spaces after the "." which is an operator....
So much for my "iffy proposition".  :-)

(I did once design a language which cared about whether you had spaces
between a term and an open paren, so (f (x)) was a pair while (f(x))
was a function application, ... I managed to justify that to myself.
As I recall, Tim razzed me for it.  :-)

      -- sandro

[1] http://lists.w3.org/Archives/Public/www-rdf-interest/2003Jul/0112.html

Received on Monday, 14 July 2003 09:20:15 UTC