http?X and https?X are different URIs.  You may fetch a document containing
a serialized graph using TLS but that is quite separate from the URIs that
may be used as identifiers.

In fact, the denotation of  a IRI used to name a graph is explicitly
unspecified (I am having to craft a semantics for applying PROVO to such an
IRI (so that provenance can be asserted over a bunch of related statements
with reification implicit, and without having to accept an entire graph).

TLS does not provide the security properties you may need (privacy is weak,
and non-repudiability  not available).

Simon
Connecting two recent c4l threads... It seems that the web is rapidly
moving toward https. I'm tempted to wonder how soon it will be before https
is the default protocol when you type a bare domain name into your browser?
[1] With linked data we want cool URIs, where one element of coolness is
persistence. If it is likely that http URIs will be seen to be "unclean"
[2] in the near future that would surely be a pressure to change them.
Should we just go ahead and always use https URIs for linked data now?

Cheers,
Simeon

[1] Of course you can do this yourself much of time with HTTPS Everywhere <
https://www.eff.org/https-everywhere> but I really mean when is it so much
the norm that chrome/firefox/safari/etc. do that expansion out of the box,
instead of assuming http.

[2] Perhaps snoopability of http traffic doesn't matter in the bulk harvest
case but in the case of an individual following a link, any use of an http
URI could leak significant info about what is being looked at even the
server immediately redirects to an ssl page.