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: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
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen