- From: Alexandre Bertails <bertails@w3.org>
- Date: Thu, 11 Oct 2012 11:19:51 -0400
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- CC: Henry Story <henry.story@bblfish.net>, public-ldp-wg <public-ldp-wg@w3.org>
On 10/11/2012 11:05 AM, Andy Seaborne wrote: > > > On 11/10/12 15:34, Alexandre Bertails wrote: >> On 10/11/2012 10:15 AM, Alexandre Bertails wrote: >>> On 10/11/2012 09:56 AM, Andy Seaborne wrote: >>>> >>>> >>>> On 11/10/12 13:46, Alexandre Bertails wrote: >>>>> But imposing >>>>> absolute URIs to define RDF graph is plain wrong, and highly >>>>> impractical. >>>> >>>> Do you agree the RDF specs do require absolute URIs as those specs are >>>> currently written (or drafted in RDF 1.1)? >>> >>> I agree that people working with RDF databases don't have any >>> incentive to deal with relative URIs, as everything being absolute >>> helps having identifiers that don't change, so it's easier for them. >>> >>> I believe that when it comes to data *on* the Web (so you can use >>> URLs), then you can always provide a context to resolve relative >>> URIs. Despite the stack being called Semantic Web, the use case where >>> things are not the Web is not properly handled. >>> >>> At the end, I don't see the difference with a browser getting a HTML >>> document... You have all the URLs being resolved to absolute URLs, and >>> that's what matters at the end of the day. >> >> And to reply more directly to your question: of course you're right, >> there is no such thing as relative URIs in RDF per definition. And >> many of the specs and implementations rely on this property. >> >> But here is the thing: this applies only when one says "here we need >> an RDF Graph". Here is my point: if we need a weaker definition for an >> RDF Graph where URIs can be relative, then let's just do it. Whenever >> we want to combine this with another spec that asks for an plain-old >> RDF Graph, then it means that we have to provide the base URI to >> resolve it. >> >> We just have to provide a definition for a Relative RDF Graph and make >> an explicit reference to http://tools.ietf.org/html/rfc3986 . I >> believe that this does not introduce any incompatibility with RDF and >> does not even need to be brought to the RDF WG. This is definitely in >> scope for LDP. >> >> What do you think? > > I think it's a massive step! Forking the basic stack splits the > community. What community are we talking about? I believe that the SPARQL people and the LDP people don't try to achieve the same goals. Not supporting relative URIs while we're exchanging RDF documents on the Web just does not make sense. This is what makes LDP compelling. The point is: people will do it anyway. And these people are probably not the ones using a SPARQL database today. I mean, if I don't care about relative URIs and LDP, I already have SPARQL 1.1! > No existing software to reliably build on. I'm still not convinced by this argument. As I said, one can use existing software as a basis and adapts the parts that need to be adapted (as we already do in banana-rdf). Of course, it would be better if existing software would support the relative graphs from the beginning :-) > > (Jena hacks do not count, especially ones that bypass the RDF API and go > straight to the system API. And they aren't uniform, its just the Java > RDF API that does not check for efficiency reasons - the contract is RDF.) > > A better framing is that LDP is document manipulation. I'd prefer to have a proper way to speak about those things than relying on some wording as a workaround. Alexandre. > > Andy > >> >> Alexandre. >> >>> >>> Alexandre. >>> >>>> >>>> Andy >>>> >>> >>> >>> >> >
Received on Thursday, 11 October 2012 15:20:35 UTC