- From: Michael Kifer <kifer@cs.sunysb.edu>
- Date: Fri, 02 May 2008 00:50:38 -0400
- To: Sandro Hawke <sandro@w3.org>
- Cc: Axel Polleres <axel.polleres@deri.org>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
The problem is that you are getting carried away manipulating characters
and are completely forgetting about the meaning of the symbols that you are
playing with. Let's look at this piece from your email.
Instead of:
"http://purl.org/dc/terms/creator"^^
"http://www.w3.org/2007/rif#iri"^^
"http://www.w3.org/2007/rif#iri"^^
"http://www.w3.org/2007/rif#iri"^^
...
we can chop it any point, like:
"http://purl.org/dc/terms/creator"^^
"http://www.w3.org/2007/rif#iri"^^
<http://www.w3.org/2007/rif#iri>
or:
"http://purl.org/dc/terms/creator"^^
<http://www.w3.org/2007/rif#iri>
If you pause for the next 30 seconds about it, you should realize that none
of the above makes ANY sense. If you did figure it out, then skip the next
block.
/*
Read next only if you could not figure out the above riddle.
Otherwise,
goto PROCEED
*/
Solution:
In foo^^bar, neither `foo' nor `bar' is a constant. Only the entire foo^^bar is.
So, the above
"http://purl.org/dc/terms/creator"^^
"http://www.w3.org/2007/rif#iri"^^
<http://www.w3.org/2007/rif#iri>
and its siblings is total bull.
If you have the time to define a different RIF language in which the above
will have a meaning then please do so asap.
/********* End optional text **********************************/
PROCEED:
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"^^"http://www.w3.org/2007/rif#iri"
2. A ^^-occurrence:
"abc"^^foo:bar ----> "abc"^^"expand(foo)bar"
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.
Hope it makes things clear.
--michael
PS. I vaguely remember that Jos may have proposed something similar in the
past. I did not like it at the time due to context sensitivity, but I
am giving up now.
> > > > "http://purl.org/dc/terms/creator"^^'http://www.w3.org/2007/rif#iri'
> > > >
> > > > or with double quotes.
> > >
> > > Yeah, or the standard URI delimiter characters "<" and ">".
> > >
> > > I could live with double quotes, but I (and perhaps you) will get a lot
> > > of WTF looks from people who see we took ^^ from N3/N-Triples/Turtle and
> > > then oddly used quotes for URI delimiters instead of "<" and ">". If we
> > > use double quotes, I might suggest we change from a^^b to something like
> > > datavalue(a,b).
> >
> >
> > This is why I think it is better to leave it underspecified and let people
> > use their imagination. First, our spec allows for aliases to symbol spaces
> > and aliases do not need to be IRIs (only the main identifiers). So, it
> > would be strange to write
> >
> > "http://purl.org/dc/terms/creator"^^<http://www.w3.org/2007/rif#iri>
> > vs
> > "http://purl.org/dc/terms/creator"^^foobar
>
> That doesn't seem at all strange to me, in the style of N3-inspired
> languages that use URIs (surrounded by "<" and ">") as terms. I expect
> to be able to use these...
>
> <http://purl.org/dc/terms/creator>
> dc:creator
> myCreator [ a local term ]
> ?myProp [ a variable ]
>
> in the same positions in the grammar, in general. (Obviously there may
> be some restrictions, like variables in the predicate position.)
>
> > Second, our presentation syntax, not being a concrete syntax, is lacking in
> > details in many other ways, so why should we spend so much time filling in
> > the details of this particular piece of syntax?
>
> I hear that you don't think this is important, but several other WG
> members think this particular bit of the syntax it is quite important to
> nail down. Do you think it has to take much more time? I'm hearing
> that you find this distasteful, but not that it's actually broken.
>
> > Third, I think that <http://www.w3.org/2007/rif#iri>
> > should stand for "http://www.w3.org/2007/rif#iri"^^rif:iri, since
>
> You mean, even on the right side of the ^^ ?
>
> You don't like
>
> "http://purl.org/dc/terms/creator"^^<http://www.w3.org/2007/rif#iri>
>
> because it should be
>
> "http://purl.org/dc/terms/creator"^^"http://www.w3.org/2007/rif#iri"^^rif:iri
>
> ?
>
> My point is that you have to end the recursion somewhere, and N3 ends it
> at terms like <...>.
>
> So I see two decent options:
>
> 1. Allow a new kind of Const, with the syntax '<'+urichar*+'>',
> which is understood to mean exactly the same thing as
> '"'+urichar*+'"' with the symbol space identified by the URI
> "http://www.w3.org/2007/rif#iri". But we don't rewrite it
> that way, because we'd have infinite recursion. Instead of:
>
> "http://purl.org/dc/terms/creator"^^
> "http://www.w3.org/2007/rif#iri"^^
> "http://www.w3.org/2007/rif#iri"^^
> "http://www.w3.org/2007/rif#iri"^^
> ...
>
> we can chop it any point, like:
>
> "http://purl.org/dc/terms/creator"^^
> "http://www.w3.org/2007/rif#iri"^^
> <http://www.w3.org/2007/rif#iri>
>
> or:
>
> "http://purl.org/dc/terms/creator"^^
> <http://www.w3.org/2007/rif#iri>
>
> or, of course, just:
>
> <http://purl.org/dc/terms/creator>
>
> 2. <foo> expands to
>
> lit("foo", "http://www.w3.org/2007/rif#iri")
>
> a:b expands to
>
> lit( concat(expand(a), expand(b)),
> "http://www.w3.org/2007/rif#iri" )
>
> Do both of these make sense? I'd imagine you prefer the latter, but
> can you live with them both?
>
> -- Sandro
>
> > in turtle these things are analogous rif iri's
> > (in RIF http://www.w3.org/2007/rif#iri is something that happens to look
> > like a URI, which "http://www.w3.org/2007/rif#iri"^^rif:iri is an IRI).
>
Received on Friday, 2 May 2008 04:51:32 UTC