Re: Linked Data Platform ISSUE-20: What is the base URI of a POSTed document?

On 10/11/12 11:19 AM, Alexandre Bertails wrote:
> 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.

+1

Kingsley
>
> Alexandre.
>
>>
>>      Andy
>>
>>>
>>> Alexandre.
>>>
>>>>
>>>> Alexandre.
>>>>
>>>>>
>>>>>      Andy
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen