Re: Ed's / Ian's View

and the other reply [split them :)]

David Booth wrote:
> On Tue, 2011-04-05 at 17:46 +0100, Nathan wrote:
>> Hi All,
>>
>> I think Ed and Ian's view can be summarized as follows:
>>
>> At the abstract level, you make statements about typed resources rather 
>> than just resources, so rather than saying:
>>
>>    dc:creator(x, "alice");
>>    foo:mass(x,2140);
>>
>> You're actually saying:
>>
>>    dc:creator(U₁(x), "alice");
>>    foo:mass(U₂(x), 2140);
>>    and.. disjoint(U₁(x), U₂(x));
>>
>> Where U₁ and U₂ are different universes, on the web, and not on the web.
>>
>> Over the years this has been surfaced in many ways, different examples 
>> include:
>>
>>    <x> :accessibleVia "x"              == U₁(x) U₂(x)
>>    *<x>  foaf:isPrimaryTopicOf <x>     == U₂(x) U₁(x)
>>    _:x foaf:isPrimaryTopicOf <x>       == U₂(x) U₁(x)
>>    tdb:x foaf:isPrimaryTopicOf <x>     == U₂(x) U₁(x)
>>
>> and the inference one (Ed's William Shakespeare example, and as outlined 
>> above), which is to have the properties specify whether <x> in the 
>> surface syntax is referring to U₁(x) or U₂(x).
>>
>> The William Shakespeare example / universe inference approach was 
>> falling apart when it came to properties like dc:creator on resources 
>> like wikipedia pages about Books, which to IanD's credit he pointed out, 
>> and to which Ed responded by effectively saying "well we need a separate 
>> ontology for talking about things in U₁".
>>
>> Other cases mentioned (by IanD and others) take the approach of saying 
>> things like "I'll only use x to refer to things in U₂, not U₁", which 
>> was later expanded on with the Content-Location suggestion to 
>> effectively say "I'll only use x to refer to things in U₂, not U₁, and 
>> if I need to refer to things in U₁ I'll provide some other name for that 
>> thing" ... but I think it still had the same sentiment of using the 
>> properties to suggest whether the thing being discussed was in U₁ or U₂, 
>> for example by saying <x> a :Person, or <x> a :Document but not both.
> 
> Nice summary.  All of these approaches fall apart upon examination.

Hmm, I'm unsure all do, certainly a new set of ontologies and Ed's infer 
one could be incorporated somehow, indeed it may be the only way to 
clean up the current mess many (<billion) resources are in atm with name 
mix ups..

>> To me this outlines that:
>>
>> - there's a kind of distinction being made by people that there are two 
>> classes of resources, the documents/irs/things on the web, and the 
>> everything elses. (there are two unvierses)
> 
> Right, but this dichotomy is a mirage.  It is neither necessary nor
> sufficient, and the basic reason comes back to the fundamental ambiguity
> in the identity of any resource.  The IR/non-IR distinction is merely
> one example of what occurs whenever one makes a finer distinction about
> the identity of a resource r, distinguishing the X-aspect of r from the
> non-X-aspect of r.  It doesn't matter what the X-aspect is -- the
> principle is the same.  I tried to explain this in a rough draft here:
> http://dbooth.org/2007/splitting/
> Some day I should get around to finishing that document, but hopefully
> the ideas will be clear enough.

Isn't that ambiguity in interpretation? and is that the same issue or a 
different one? If people see things as either being on the web or not, 
then that's something we need to take in to account.

>> - that one approach is to use properties to say which universe the x you 
>> are talking about belongs in ( use x to refer to both U₁(x) and U₂(x) )
> 
> That's Ed's approach, right?  Okay for some limited cases, but won't
> work as a general solution.

Yes, it's Ed's approach - with the correct ontologies and people 
actually using them, and, machines set up to interpret properly, it 
could work pretty well for certainly most, if not all, cases I can think 
of. Is it not the same as your resource splitting? it just builds the 
information required to resource split in to the predicates so it can be 
done on a per triple level, and on demand. Perhaps I'm missing something?

>> - that another approach is to only use x to refer to either U₁(x) or U₂(x)
> 
> But it does not solve the problem -- it only postpones it.  The exact
> same problem still shows up in other ways, because the root of the
> problem is the fundamental ambiguity of resource identity, and the fact
> that what is unambiguous to one application may be ambiguous to another
> application that requires finer distinctions.

Fully agree, far better just to say x and y :)

>> - that another approach is to use some surface syntax (quotes or *) or 
>> other form of uri (tdb:) to refer to either U₁(x) U₂(x).
> 
> Syntax cannot solve the problem either, because it is a *semantic*
> problem.

Agree re syntax, it would need two classes of names in the model to even 
be roundtrip-able (else syntax split gets lost in translation), tdb: 
however is of course a different name so gives us x and y that is 
needed. But again requires special things, and people will pushback to 
"normal" http:// URIs anyway, so perhaps a lost cause.

>> And that currently our solutions are:
>>
>> - to use absolute iris for things in U₁, and frags for things in U₂
>> - to use x to refer to things in U₁ and y to refer to things in U₂, 
>> where 303(x,y)
> 
> Right, but as I mentioned above, this does not solve the problem either.
> It merely postpones it.

Hmm, the first of the two above seems to make a "no problem" situation 
afaict, and the second of the two deals with the social problem that 
people were told "you can name anything with any uri" ... "oh wait but 
not these ones in this special case!". Any other things we add to that 
list that don't deal with a fundamental use-case is only going to make 
matters worse imho.

That said, what problem are you talking about here, that is being 
postponed? The things are open to interpretation one (which is the point 
of interpretation?) or something else? I don't think I fully understand 
which problem you are referring to! (but I'm listening)

Best,

Nathan

Received on Tuesday, 5 April 2011 22:01:13 UTC