W3C home > Mailing lists > Public > public-rif-wg@w3.org > May 2008

Re: DTB status (on today's agenda)

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Fri, 02 May 2008 12:36:30 -0400
To: Sandro Hawke <sandro@w3.org>
Cc: Axel Polleres <axel.polleres@deri.org>, debruijn@inf.unibz.it, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
Message-ID: <15328.1209746190@cs.sunysb.edu>


Sandro wrote:
> 
> > Jos de Bruijn wrote:
> > > 
> > > 
> > > Sandro Hawke wrote:
> > >>> 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"
> > >>
> > >> 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.
> > > 
> > > I thought that in RIF ^^ is also always followed by an IRI constant?
> > 
> > In those other languages you are speaking about, it is followed by a IRI 
> > in angle brackets or a CURIE:
> > 
> > N3: http://www.w3.org/TeamSubmission/n3/
> > 
> >     literal ::=	string dtlang
> >     dtlang ::=   "@"  langcode |	 "^^"  symbol
> >     symbol ::= explicituri | qname
> >     explicituri ::= <[^>]*>
> >     qname ::= /* what we called CURIE */
> > 
> > Turtle: http://www.w3.org/TeamSubmission/turtle/
> > 
> >     literal ::=  quotedString ( '@' language )? | datatypeString
> >                  | integer | double | decimal | boolean
> >     datatypeString ::= 	quotedString '^^' resource
> >     resource ::= uriref | qname
> >     uriref ::= '<' relativeURI '>'
> >     qname ::= /* what we called CURIE */
> > 
> > 
> > SPARQL: http://www.w3.org/TR/rdf-sparql-query/
> > 
> >   RDFLiteral ::= String ( LANGTAG | ( '^^' IRIref ) )?
> > 
> >   IRI_REF ::= '<' ([^<>"{}|^`\]-[#x00-#x20])* '>'
> > 
> >   Note: No CURIEs allowed in the Grammar there for the type, although
> >       they use CURIEs in the examples in the spec... actually, that 
> > seems to be a bug in their grammar.
> > 
> > 
> > 
> > 
> > > I think we should stick with the ^^ in RIF, because its use actually 
> > > generalizes the use in the other semantic Web languages.
> > 
> > I fully agree that RIF presentation syntax should generalize those 
> > languages, yes. We already defer by putting the langtag in side the 
> > string, BTW.
> 
> Right, but Michael is adamantly against RIF-PS generalizing those
> languages.  So, I can live with this other approach.   No pointy
> brackets and no ^^.
> 
>       -- Sandro

I do not understand. In what sense isn't it (the proposal in my message) a
generalization?

Let me correct an inaccuracy in your message:

> 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 RIF, the part after the ^^ is not a string constant -- it is not a
constant of any kind. But it is an IRI in most cases (a sequence of chars
that amounts to an IRI).  The fact that these other languages call that
part a "constant" does not make it so. They can call it a foobar, if they
please.  Can they write "abc"^^?X (a variable)? If not, then the ^^ part is
just an integral part of the "abc"^^xsd:string constant.

Now, if you want to ditch the ^^ syntax, I do not object. But the lit(...)
syntax is too verbose. And I do not understand in what sense does RIF
contravene the usage of ^^ in other languages.


	--michael  
Received on Friday, 2 May 2008 16:40:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:48 GMT