Re: LDP Minutes of June 3 - straw-poll ?

On 6/4/13 3:07 PM, Wilde, Erik wrote:
> On 2013-06-04 11:58 , "Roger Menday" <Roger.Menday@uk.fujitsu.com> wrote:
>>>>>>> My characterisation:
>>>>>>>
>>>>>>> 1. Managing Documents (about Things) in Boxes
>>>>>>> 2. Use Boxes to help managing Things (which might be inside
>>>>>>> Documents)
>>> [...]
>>>>>> That why I say that Boxes are just a means to an end (rather than
>>>>>> the end themselves). Boxes just contain the membershipTriples.
>>>>> Boxes are LDPCs if I understand. The membershipXX are really attempts
>>>>> to declare certain things.
>>>>>
>>>>>>> The use case people are trying to solve with the propertyXX
>>>>>>> relations I think needs to
>>>>>>> be worked out and described carefully. The the idea would be to
>>>>>>> find some patterns
>>>>>>> that allow you to  satisfy the use case of adding  relations in
>>>>>>> connected LDPRs when creating an LDPR.
>>>>>>>
>>>>>>>> I believe that no.2 is where more applications are.
>>>>>>> Since you can do everyting with 1, you can't claim there are more
>>>>>>> applications in 2.
>>>>>> That's true.
>>>>>> So one can do everything with both models :)
>>>>> I was saying you can do everything with 1. What is up with 2
>>>>> I don't know. It is really not clear.
>>>>>
>>>>>> Which one is the mainstream developer going to be happier with ?
>>>>> Something that works. I am sure 1 works. 2 is not clear at all.
>>>>> 1 is Atom semanticised: devs can leverage a lot of knowledge to
>>>>> understand that. 2 seems like OO thinking applied to the web, which
>>>>> seems like XMLRPC.
>>>> So, no.2 is interesting because I think it is the best basis for doing
>>>> hyperRDF, and that seems pretty far away from the accusations you are
>>>> making. Anyway, you can't say "don't understand no.2" and then toss
>>>> around "it's just XMLRPC" !! I am trying to understand why you want to
>>>> do semanticisedATOM btw ... :)
>>> To explain how I come to "XMLRPC" : you speaks of manipulating "things"
>>> (aka objects)
>>> remotely: that seems to  be an OO programming way of thinking of the
>>> matter.
>>> OO has a problem of  not being able to distinguish between contexts -
>>> who
>>> said what [1] - and it is the way of thinking developers have been the
>>> most
>>> liable to fall into, and which has led to some of the biggest failures
>>> in
>>> distributed systems.
>>>
>>> The web in general and the semantic web in particular fall in the
>>> declarative
>>> way of programming ( eg: prolog,  reasoning systems, etc.... ) . There
>>> you
>>> express what is the case, by making statements through what in
>>> linguistics
>>> is known as speech acts, for which the equivalent on the web are our
>>> HTTP
>>> verbs: GET, PUT, POST, DELETE... The importance of declarative systems
>>> is that they can be loosely coupled and they can scale.
>>>
>>> In these declarative system it is not object that you manipulate but
>>> documents. Documents
>>> when interpreted describe restrictions on the set of ways the world can
>>> be. The
>>> semantic web makes it easy to merge RDF documents, which when done
>>> creates a new
>>> graph which creates restrictions that are the intersection of the
>>> possibilites
>>> expressed by each document. So manipulating documents, you are
>>> manipulating
>>> possibilites - not objects. In fact it is just the opposite of
>>> manipulating
>>> objects.
>>>
>>> Now the danger is that you can spend a lot of money in vain building
>>> systems
>>> that will crumble if you fail to make this distinction. The web is an
>>> global
>>> communication system, not an object interchange system - or at least
>>> the only
>>> objects interchanged are representations of documents.
>> Thanks for your comments, Henry.
>> We (this group) have exchanged a lot of examples over the past 6 months,
>> in which Thing and Document has been mixed-up. I am very sure that if I
>> look back through the archives, I would even be able to find examples
>> where YOU are doing the same thing :)
>> So, I don't necessarily disagree with your point above, I just don't
>> think that it a good argument against approach no.2, because, I think
>> that no.2 is really doing very Webby things to make Linked Data
>> interactable (i.e. readable and writeable).
> on a related note, just today the W3C published a FPWD of a "URLs in Data
> Primer" http://www.w3.org/TR/2013/WD-urls-in-data-20130604/ ; essentially
> what it says is that instead of using the funky httpRange-14 dance, what
> you should do instead is at the model level clearly distinguish and expose
> different URIs to documents about things and things themselves, if it
> matters to what you're doing.
>
> cheers,
>
> dret.
>
>
>
>
Entity disambiguation always matters, irrespective of denotation mechanism.

Nothing has changed. A Person and a Document about a Person remain 
disjoint entities. As a Linked Data publisher, you have to use URIs to 
denote both entities unambiguously -- while also taking responsibility 
for resolution.

The subjectively funky dance remains, especially when the context is 
Linked Data :-)

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen