Re: Top level points

Jonathan Rees wrote:
> 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?

Yes

>> 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.

Yes

>> 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.

Yes exactly, this is the case I was trying to capture, (2) doesn't 
mention set B, this one does specifically (that converse mistake people 
make, perhaps it's not a mistake).

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

I've not been clear enough :) It means we'd have two disjoint sets of 
names (abs and frag) each of which can only be used to refer to one of 
the two disjoint sets of thing (A and B). As in, absolute-IRI always 
refers to things in set A or nothing. frag-IRI always refers to things 
in set B, or nothing. (as opposed to 2 where frag-IRIs can refer to 
anything, and 1 where all IRIs can refer to anything).

>> 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,

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).

Wise move (and I've always liked that as described by terminology!)

> (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.

Which is fine - we can cover that! (optimistic lol).

>> 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?

nope just the one, because we've generalized, one universe, containing T 
the set of all things (the scope for quantification) which is split in 
to two disjoint sets of things, A and B, the union of which is T.. and 
thus blank nodes are existentially quantified in the universe which is 
T. If it exists, it exists in the universe. So we'd need a something like..

   ∀x[x∈A∨x∈B]∧¬∃x[x∈A∧x∈B]

> 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?

No name changing, something cannot be a member of both A and B. Whether 
a particular member of A or B exists at a certain time doesn't matter, 
only that it cannot exist in A at some time and then in B at another time.

Can you give me an example of anything that could exist outside of the 
web one day, and on the web the next?

> 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.

Fully agree.

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

Yup, sigh.

>> 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.

Because they'd previously been told (1) I think, but can't change the 
past now.

Although.. things could be layered, for instance if a new set of specs 
were made which layered on top of the RDF semantics, which had three 
classes of persistent names (for A, B and bnodes), and were defined in 
terms of simple sets (ground graphs) and focussed around data management 
and linked data, then it could solve all these linked data centric 
problems, and also back port on to RDF since it would just need a simple 
translation from the three classes of names to the two present in RDF 
(URI-ref and blank node identifier) and would thus be backwards 
compatible and full reasonable with RDF tooling etc (it's just be 
turning it from one syntax to another, or from one data model/api to 
another) - it could be done and give "linked data" a fresh start which 
builds on the good stuff and remains semantic web compatible..

>> 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?

Ahh most of them are the same really, the above simply would mean that 
all statements currently made about </> would suddenly be made about 
</#>, giving meta (data about things on the web) a clean slate to start w/.

> 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.

well.. if you were fixing up RDF, which doesn't seem feasible to change, 
if starting with a clean slate and backwards compatibility of tooling, 
rather than data, in mind, then it'd be possible to do (and any upgrade 
by data producers from RDF to whatever would auto fix them).

Other than that though, it increasingly seems like stepping back to '89, 
keeping the status quo, or going with the property sets the 
class/universe approaches are about the only realistic options at the 
end of this, for RDF.

Best,

Nathan

Received on Tuesday, 5 April 2011 19:45:45 UTC