Re: URI Comparisons: RFC 2616 vs. RDF

On 1/17/11 4:54 PM, Nuno Bettencourt wrote:
> Hi,
>
> thank you for the suggestion. This had been a problem before, which in fact becomes easier to solve like that.
>
> In my current situation, we were dealing with public/private/protected resources (files), secured by https.
>
> So, if a person/agent has a private/protected resource (file) (that only shares with some specific individuals and is only accessible using https protocol) it would be hosted under https://server/abc.html.
>
> For this, I would have for example, the following triple:
>
> 1) http://server/#me dc:publisher https://server/abc.html
>
> Nevertheless, if afterwards I publically publish that resource (file), for technical reasons that same resource (file) would be given a new URI http://server/abc.html so that it would not require authentication and a new triple would be created (for terms of simplicity I'm omitting other triples that are generated):
>
> 2) http://server/#me dc:publisher http://server/abc.html
>
> In fact, both those resources (files) are the same, mapped for the same physical file but while the first required SSL credentials, the second does not.
>
> In order for those users who before had access to the private resource, to keep accessing the resource, since it is now public (but has been moved from protected), I would had a triple in order for the semantic system to be able to retrieve the same resource, since it is no longer available under its original location.
>
> 3) https://server/abc.html owl:sameAs http://server/abc.html

But at this point your context has changed, you are now make an 
assertion in a deductive data space. Basically, a record that is also a 
proposition re. RDF (or any other) deductive system. Again, the moment 
you make a triple, you are making a propositional statement. And the 
moment you do that, in the context of HTTP based Linked Data, it has to 
be something like this:

https://server/abc.html#this owl:sameAs http://server/abc.html#this .

If you don't care about Linked Data via HTTP user agents following links etc. ; meaning you're happy with a local graph of propositions that is SPARQL queryable, for instance, then this works too:

https://server/abc.html owl:sameAs http://server/abc.html .

> This unfortunately leads to a minimal and probably unrealistic problem like an open URI https://server/abc.html that might not have any content, since there's no need for it as it has become public and no authentication is needed for accessing it - but it is necessary to keep that triple 1) alive  as others might be consuming that information. Triple 3) helps those in finding the resource again.
>
> One and more rich possible solution might be implementing time reasoning mechanisms over this, in order to eliminate those 'fake' URIs, but that would grow the triple store and make reasoning even more time consuming (for now).
>

No need for fake URIs (I guess you might think the #this above == fake), 
it's just comes down to Name References and the need for them to resolve 
to something useful, which may or may not be useful (e.g. navigable) to 
an HTTP agent, or deliver factual basis for inference by a deduction 
oriented engine (logic reasoner).

I hope this helps.


Kingsley

> Nuno
>
>> -----Original Message-----
>> From: Nathan [mailto:nathan@webr3.org]
>> Sent: segunda-feira, 17 de Janeiro de 2011 18:06
>> To: Nuno Bettencourt
>> Cc: public-lod@w3.org
>> Subject: Re: URI Comparisons: RFC 2616 vs. RDF
>>
>> Nuno Bettencourt wrote:
>>> Hi,
>>>
>>> The doubt just kept on because in all protocols we were still referring to
>> the same URN.
>>
>> do you mean that there were RDF statements which linked each of the
>> protocol specific URIs to a single URN via the same property? eg:
>>
>>     <http://...>  x:foo<urn:here>
>>     <https://...>  x:foo<urn:here>
>>     <ftp://...>  x:foo<urn:here>
>>
>> If so, then you could define the property (x:foo above) as an Inverse
>> Functional Property which would take care of the sameness for you.
>>
>> Best,
>>
>> Nathan
>
>


-- 

Regards,

Kingsley Idehen 
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Monday, 17 January 2011 22:32:49 UTC