Re: DTB status (on today's agenda)

> Let me reiterate (for the third time) my extremely simple compromise
> proposal.  Here expand(foo) means substitute with the prefix definition of
> foo.
> 1. Standalone occurrence:
>     foo:bar ---> "expand(foo)bar"^^""
> 2. A ^^-occurrence:
>     "abc"^^foo:bar ----> "abc"^^"expand(foo)bar"

I can live with this, if we don't use "^^".   This was the second option
in my e-mail, although I accidentally expanded bar as well.

The problem with ^^ is that it's very distinctive and is used in other
semantic web languages.  But in those languages, it's followed by a URI
constant not a string constant.    So I'd have to object that re-using
^^ with this kind of type difference is too confusing to users.

In my previous e-mail I wrote  a^^b as lit(a,b), which seems about
right.   I'm not sure what we should call "lit".   SWI-Prolog calls in
"type(b, a)". [1] 

I suppose the obvious thing is "Const", so the change in the grammar is:


   Const          ::= '"' UNICODESTRING '"^^' SYMSPACE

Add (trying to keep current style):

   Const          ::= 'Const(' '"' UNICODESTRING ',' '"' SYMSPACE '"' ')'

Does that work?

I'd also consider putting the symspace first (as in SWI-Prolog), because
in a sense it's the most-significant part.

> If you do not like "..." for the after the ^^-part, use '...' or even <...>.
> But, in the latter case, <...> CANNOT be used as a macro. That is,
>    <abc>  --X--> "abc"^^rif:iri.
> is a no-no.
> My proposal allows some simple form of context sensitivity, but not the
> above <...> macro atrocity (if <...> is also used after the ^^).
> I do not see why we need such a macro in the first place, if in most cases
> we will be using foo:bar.

I can't think of any reason we need "<" ... ">", but we might.   I think
we can leave them out until/unless we need them.

      -- Sandro


Received on Friday, 2 May 2008 13:19:52 UTC