# Re: Ed's / Ian's View

From: Nathan <nathan@webr3.org>
Date: Tue, 05 Apr 2011 23:00:23 +0100
Message-ID: <4D9B90F7.3040705@webr3.org>
To: David Booth <david@dbooth.org>
CC: AWWSW TF <public-awwsw@w3.org>
```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
>> 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 April 2011 22:01:15 GMT