W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2015

Re: xsd:anyURI syntax

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Fri, 20 Mar 2015 09:10:18 -0700
Message-ID: <550C466A.7090405@gmail.com>
To: Arthur Ryman <arthur.ryman@gmail.com>, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Hash: SHA1

The benefit is representational cleanliness.  The literals of type
xsd:anyURI are being turned into bits of SPARQL code, which are character
strings that are of the form of IRIs.

If you don't care about representational cleanliness then I don't expect
that you would see any loss using actual IRIs.

I prefer representational cleanliness, but there are many compromises that I
would be prepared to make to get to an agreement, and this would be one of them.


On 03/17/2015 03:32 PM, Arthur Ryman wrote:
> Peter,
> Please explain the benefit of using literals of type xsd:anyURI instead
> of IRIs.
> The downside is that you'd have to explicitly convert the literals to 
> IRIs in typical SPARQL queries using IRI() or URI(). This could be very
> awkward.
> -- Arthur
> On Tue, Mar 3, 2015 at 11:34 PM, Holger Knublauch 
> <holger@topquadrant.com> wrote:
>> Spawning off a thread on the choice of using xsd:anyURI. I anticipate
>> it is pretty obvious which syntax most users would prefer:
>> shacl:classScope"http://example.org/Person"^^xsd:anyURI ;
>> or
>> shacl:classScope ex:Person ;
>> so maybe you should clarify why you made that suggestion. You quoted 
>> "representational purity" and "to separate use and mention" but as a
>> WG member I would not want to receive death threats from users who are
>> no longer allowed to write qnames in their Turtle and JSON-LD files :)
>> So what practical problems do you anticipate if they would be proper
>> IRI nodes?
>> Thanks, Holger
>> On 3/4/2015 13:32, Peter F. Patel-Schneider wrote:
> I have attached a couple of examples.  (They get too messed up if I put 
> them in line.)
> peter
Version: GnuPG v1

Received on Friday, 20 March 2015 16:10:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:18 UTC