W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

RE: Questions about Update 1.1

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Sun, 18 Oct 2009 16:27:34 +0000
To: Steve Harris <steve.harris@garlik.com>
CC: Paul Gearon <gearon@ieee.org>, Gregory Williams <greg@evilfunhouse.com>, "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA3693FA2260B@GVW1118EXC.americas.hpqcorp.net>

> -----Original Message-----
> From: Steve Harris [mailto:steve.harris@garlik.com]
> Sent: 18 October 2009 16:00
> To: Seaborne, Andy
> Cc: Paul Gearon; Gregory Williams; public-rdf-dawg@w3.org Group
> Subject: Re: Questions about Update 1.1
> On 18 Oct 2009, at 15:05, Seaborne, Andy wrote:
> [snip]
> > I agree that the use of <_:..> is making an assumption that need not
> > be true everywhere.
> >
> > For SPARQL-1/Query, the WG decided not to mention it.  But with an
> > update language I think we need to face this again - at the very
> > least, decide explicitly not to cover it although personally I think
> > it does need something.
> >
> > We need <_:InternalId> but also a way to get internal names.  BNode
> > labels in result sets can be interpreted as scoped to the result set
> > only - i.e. like Turtle syntax _:a.
> >
> > If we had function  BNODE_REF(?x) then a query could get it and it
> > would allow a system to know a reference had been handed out,
> > allowing a separation between the internal ID and the reference let
> > out.  A processor can track the references and know what's been
> > revealed and what hasn't.  The released ref and the internal id may
> > be different or they may be the same - different system may choose
> > to do things either way.
> >
> > BNODE_REF returns either a string or a dubious URI of the form _:.....
> >
> > BNODE_REF or sparql:bNodeRef.  Need not be a keyword.  If give names
> > to all the operators anyway (e.g.. sameTerm), we are going to create
> > a namespace.
> Another option would be something like
>    SKOLEMIZE(?x)
> where the return value will be some URI that has some persistence, or
> a type error. The function could have a more friendly name, obviously.
> The gets round the problem where you have things like
>    SELECT ?knows WHERE { <uri> foaf:knows ?knows }
> and you don't know head of time whether ?knows will be a URI or bNode.
> It would turn a bNode into a persistent identifier, and leave URIs as-
> is.
> - Steve

Good point.  With IF(,,) it's possible but a bit ugly and union with a filter in either branch is worse.  

"Skolemize" might be a bit unfriendly (maybe a good idea given the nature of the usage)

I prefer not using a keyword of the language but only a custom function form to emphasis the fact it's a non-core feature. sparql:ref(?x) ?

May or may not apply to literals -- if it does, it returns the literal.


Received on Sunday, 18 October 2009 16:28:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:58 UTC