Re: Top level points

On Tue, Apr 5, 2011 at 1:29 PM, Nathan <nathan@webr3.org> wrote:
> Hi,
>
> Just noticed something at the top level, let's quickly make three sets.
>
>  T = the set of all things
>  A = the set of all things on the web
>  B = T-A, the set of all things not on the web.

I think that you are using "on the web" the same way I am using
"accessible via some URI". Does that sound right?

> Okay, when it comes to "naming", there are a few different approaches.
>
> 1) X the set of all names
>   - any name can be used to refer to anything
>
> (this is the current approach, with "special cases" for things on the web,
> e.g. 303)
>
> This implies to some people that..
>
> 2) there exists a set Y of absolute-IRIs which refer to things in set A
>   and, there exists a set Z of hash-IRI which can be used to refer to things
> in set T (anything).

Let's take this apart. We have XA = the set of absolute-IRIs, XH = the
set of hash-IRIs. Both are subsets of X.
Y = {u in XA such that u refers to something in A}  ... which exists
by construction... might be empty
Z = {u in XH such that u can be used to refer to something in T}
Since XH is a subset of X, by premise 1, anything in XH can be used to
refer to anything. And since everything is in T, we can conclude that
Z = XH.

> But it also implies to some people that..
>
> 3) there exists a set Y of absolute-IRIs which refer to things in set A
this is the same as above...
>   and, there exists a set Z of hash-IRI which can be used to refer to things
> in set B (things not on the web).

Since B is a subset of T, and things in XH can refer to anything, the
last set is the same as the previous Z, or Z1 = Z2 = XH.

Maybe you mean that some people conclude that XH can *only* refer to
things in B (retracting premise 1)? This is a typical converse mistake
of the sort people make all the time.  But so be it, this certainly
happens.

> which creates two disjoint sets.
You mean, A and B?  They were already disjoint... not sure what you mean.

> and further, that syntactically the set Z
> of hash-IRIs contain the set Y of absolute-IRIs, and thus <y#z> refers to Z
> as described by y.

you mean, each hash-IRI lexically contains an absolute-IRI... yes,
this is the convention currently, but it assumes that y refers to the
document. I don't make this assumption in the writeup - to be immune
to Ian and Ed's changes I say that y#z refers to z as described by
IR(y).

(You're using brackets a bit inconsistently here.  It is not <y#z>
that refers, since <y#z> is what the URI 'y#z' refers to, at least in
the way N3/turtle use <...>.  You mean that 'y#z' refers.  And it
refers to z as described by <y> or by IR('y') - or more accurately, it
refers to what is referred to as 'z' or 'y#z' in IR('y')... usually
the latter for RDF, the former for HTML.)

> Perhaps it's a simple thing, that because we have case (1) people have loads
> of room to argue about this stuff and get confused. And because some people
> also see case (2) it can be seen "unfair" that URIs in set Z can refer to
> anything whilst uris in set Y cannot (hence 303 rule).
>
> TBH, all I see us doing is finding more ways to handle (1) and (2),

True. But this is all anyone is asking for.

> and that
> perhaps the only clean solution is to have (3), two disjoint sets of names,
> one for things on the web, one for things not on the web. (note that's
> generic to how those names surface in syntax, or where they're a particular
> form of URI/IRI, or use a certain scheme, or..).

And two kinds of blank node?

What if you don't know whether something is on the web or not?  What
if it's not on the web now, but will be next week, or vice versa - do
you have to change its name?

I wouldn't expect any retrofit of the sort demanded by the combination
of FYN and we-can't-change-the-browser to be clean. We started with
one mechanism, the hash URI. If we had stopped there we'd be done, I
believe. But people keep wanting new things. When you realize that
what's demanded is URIs you can put into a browser, it's clear that
we're completely screwed. There is no way to win.

The time to get this right would have been 1989. Oh well.

> Perhaps it would be interesting to see if people were happy, in concept,
> with having two disjoint sets of names aliasing two disjoint sets of things,
> or whether because of the last 10 years, they'd rather stick with fumbling
> between (1) and (2).

That would be interesting.

Of course we pretty much had this in the original semweb architecture,
and people didn't like it.

> For example, one solution may be that <http://example.org/foo> always refers
> to <http://example.org/foo#> and that to speak of the web resource you'd
> need <[http://example.org/foo]> or some such - many different approaches -
> point is though, perhaps it can be broken in to the 1,2,3 and let people
> first see which they'd be happiest with, as a community.

Isn't this the same as Ian's approach, at least the version without
the link to the document? I.e. what I describe in 5.6?

You'd have to deal somehow with backward compatibility, like the half
a billion CC-licensed documents that use URIs in the httpRange-14
sense, and all the current uses of rdfs:seeAlso and rdfs:isDefinedBy.

Jonathan

> Best,
>
> Nathan
>
>
>
>
>
>

Received on Tuesday, 5 April 2011 18:49:05 UTC