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

RE: rdf:text review

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Wed, 29 Apr 2009 15:02:16 +0000
To: Axel Polleres <axel.polleres@deri.org>
CC: 'RDF Data Access Working Group' <public-rdf-dawg@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA362D1328D3C@GVW1118EXC.americas.hpqcorp.net>

> -----Original Message-----
> From: Axel Polleres [mailto:axel.polleres@deri.org]
> Sent: 29 April 2009 15:51
> To: Seaborne, Andy
> Cc: 'RDF Data Access Working Group'
> Subject: Re: rdf:text review
> Andy,
> we seem to be almost there from my side. I just was tempted to
> relativize 1/ as well, since I believe it is likewise remedied by
> resorting to D-entailment effects only.
> Do you agree?

No - because I don't understand "relativize".

If you mean an rdf:text aware system can choose to expose rdf:text, then I do not agree.  The client system may well be an RDF one.  If they choose to negotiate a different format (i.e. SPARQL results with rdf:text), then they are welcome to do that (it's a pairewise agreement) but the base line should be to maximise compatibility.  rdf:text processors are already required to accept the DRF serialization.  RDF-Graph exchange requires RDF serialization; so the same should apply here.

If later standards come along and put rdf:text in RDF, then change all the related bits and piece then not plan for an unclear future.  Leaving "if", "buts" and "maybes" now just hurts inoperability.

(Also, if the rdf:text-entailment is mixed with non-rdf:text-entailment in one query, what happens?)


> As for 2/ and 3/, I am fine. We have to revisse the current response
> text accordingly, only started with that so far.
> Axel
Received on Wednesday, 29 April 2009 15:04:02 UTC

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