- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 17 Jan 2011 17:32:20 -0500
- To: Nuno Bettencourt <nuno.bett@gmail.com>
- CC: public-lod@w3.org
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