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 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). Nuno > -----Original Message----- > From: Nathan [mailto:nat...@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
