W3C home > Mailing lists > Public > semantic-web@w3.org > July 2010

Re: RDF 2.0 Wishlist - Legal RDF which I can't SPARQL

From: Mischa Tuffield <mischa.tuffield@garlik.com>
Date: Thu, 29 Jul 2010 20:12:10 +0100
Cc: Paul Gearon <gearon@ieee.org>, Damian Steer <pldms@mac.com>, Semantic Web <semantic-web@w3.org>
Message-Id: <8FBC5D8D-14C8-4D35-92CC-BC9DAE32E1D2@garlik.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>

On 29 Jul 2010, at 19:58, Andy Seaborne wrote:

> 
> 
> On 29/07/2010 6:59 PM, Mischa Tuffield wrote:
>> 
>> On 29 Jul 2010, at 18:40, Andy Seaborne wrote:
>> 
>>> On 29/07/2010 6:22 PM, Paul Gearon wrote:
>>> > On Thu, Jul 29, 2010 at 1:13 PM, Paul Gearon<gearon@ieee.org
>>> <mailto:gearon@ieee.org>> wrote:
>>> >
>>> > <snip/>
>>> >
>>> >> In a hack similar to the one I mentioned with FILTER, but you can
>>> always say:
>>> >>
>>> >> insert { graph<http://example.com/graph> {
>>> >> ?u foo:Property "something" } }
>>> >> { { select IRI("http://example.com/mylamefoafdocument`uri") as ?u
>>> {} } }
>> 
>> This is dependant on the definition of the function "IRI()", and it
>> seems odd to me, based on the function name, that it would generate an
>> illegal IRI.
>> 
>>> 
>>> but it still isn't a legal IRI.
>> 
>> :)
> 
> There is a function in "XQuery 1.0 and XPath 2.0 Functions and Operators" what might help:
> 
> fn:encode-for-uri(string) ->string
> 
> http://www.w3.org/TR/xpath-functions/#func-encode-for-uri
> 
> although it will encode "/" and ":" as well as it's intended to produce a string that can be used in a URI path segment not make a string safe to use as an IRI.
> 
> 
> The SPARQL-WG is discussing defining a core set of functions to be part of spec (so any implementation can be expected to provide them): e.g.
> 
> http://www.w3.org/2009/sparql/wiki/Feature:FunctionLibrary#XQuery_1.0_and_XPath_2.0_Functions_and_Operators
> 
> (disclosure: I produced that list - by simply looking through the F&O functions that covered datatypes required by SPARQL and made sense to SPARQL)
> 
> Either adding a <make-safe-for-absolute-iri>(string)->string or making IRI do minimal encoding necessary are possible.

Makes sense Andy, for now I am just going to have to put more smarts at the application level. If I do all of my data import via sparql update I should be able to ensure that all the data in the triplestore abides to the sparql spec, which is seemingly more tightly spec'ed. 

>> 
>>> 
>>> There are two levels here:
>>> 
>>> The syntax, that says:
>>> 
>>> IRI_REF ::= '<' ([^<>"{}|^`\]-[#x00-#x20])* '>'
>>> 
>>> but also the syntax rules in the URI RFC (now RFC 3986) including any
>>> scheme-specific rules.
>>> 
>>> Last time, IIRC DAWG decided not to copy over the full grammar for
>>> IRIs, but to put in a more general but smaller pattern.
>>> 
>>> For example, "[" "]" are only legal as delimiters for IPv6 addresses
>>> in the authority part.
>>> 
>>> Andy
>> 
>> Am guessing I should have just emailed the SPARQL WG people, but I
>> thought I would also flag this matter with the RDF 2.0 folks.
> 
> It's an RDF-maintenance question.  (not 2.0 please!)

Um, wasn't meant to be controversial there, please ignore my na´vety. But from a developers POV, the thought of being able to import data which can always be sparql'ed seems odd to me. 


> IMO SPARQL should follow, not lead, the decision for the data.  The original IRI decision in DAWG was made taking forward the reasoning that the RDF-Core group had used, just made up-to-date because by then the updated URI and the IRI RFCs had come out.

As someone not involved in either the RDF or the SPARQL work, point taken.

Thanks for the pointers, 

Mischa

> 
> 	Andy
> 
>> 
>> Cheers,
>> 
>> Mischa

___________________________________
Mischa Tuffield PhD
Email: mischa.tuffield@garlik.com
Homepage - http://mmt.me.uk/
Garlik Limited, 1-3 Halford Road, Richmond, TW10 6AW
+44(0)845 645 2824  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD


Received on Thursday, 29 July 2010 19:12:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:12 UTC