Re: ISSUE-58: the simple solution to inlined membership

On 16 May 2013, at 20:03, Richard Cyganiak <richard@cyganiak.de> wrote:

> Henry,
> 
> On 16 May 2013, at 15:48, Henry Story <henry.story@bblfish.net> wrote:
>>> The problem with the blank node approach is this. As you point out, it never makes a graph wrong to simply replace a URI with a blank node. It just omits some detail. RDF Semantics guarantee that. But. The reverse holds as well. It's not wrong for a client to undo your omission and substitute the URI back in, instead of the blank node, if the client knows for whatever reason the right URI (through a sameAs statement for example). RDF Semantics guarantee that too. Now if a client does this, and the semantics say that it can, then the information which members are inlined and which not is lost, in your proposal. So LDP would have to say that clients must not do that. This would contradict RDF Semantics. Essentially, the result would e that if clients use too high a level of OWL reasoning, then the protocol would break.
>> 
>> But that is also very true of the ldp:memberInlined. Different levels of reasoning might well increase the number of relations
>> on a member, or might merge information from one member to the next member. If the content of those members is contradictory then
>> you have a big problem. I pointed this out below. So your argument on reasoning is also an argument against ldp:memberInlined.
>> 
>> Do you agree with that? How do we sort out that problem?
> 
> No, I don't see a problem here. If data is inconsistent and you do reasoning over it, all bets are off. That's the nature of logic-based reasoning, and applies to any use of RDF and OWL.
> 
> The problem with your proposal was that a server that serves consistent data and a client that does correct reasoning can end up with a wrong result regarding whether members are inlined or not.

And how is that a problem? All that will happen is that he will fetch the same data again remotely.
Compared to the danger that inlining itself represents (see below) this seems harmless.

> 
> I might not understand the problem you tried to illustrate with your jaguar example. It looks like the server provides some additional information in the inlined data that a client wouldn't get when dereferencing the individual members: the fact that both price entities are the same. This seems harmless to me.

Yes, and what if different content were contradictory?  It is so easy to imagine situations like this: 
take a collection of relations where different points of views are expressed about a murder scene. 
Clearly I hope you don't suppose that all these witnesses to the murder will be in complete agreement 
with each other from the get go. Not all links from one content to another need to be a link that suggests
that merging the two sets of data is a good idea.  This is something I don't get the feeling the Linked Data
community has thought through carefully.

The notion of inlining seems to me either:

1. Extreemly likely to mislead developers implementing LDP, who could way too easily end up creating inconsistent graphs. 
There needs to be text in the spec warning people about the types of data that can be inlined, and of the consequences  of inlining.
The safest type of data one can put on a member  in an LDPC are the type of metadata relations  used in Atom and Dublin Core. 
Most other types of relation I think are a bad idea for attaching  to members in an ldpc. 

2. Secondly if you publish just metadata on an LDPR then the content will hopefully be something extra, And then it is
quite simple: either the LDPC publishes the quoted content for an LDPR in which case there is no need to fetch the original,
or the quoted content is not published in which case one should go and fetch the LDPR.

3. an LDPC in the end should be something a default apache server could put together, with no special tweaking.
It should be something that works out of the box. As it is the spec is turning into something that only owl reasoning
specialists could put together without messing it up.

That is why the real problem for this group has to be: could the use cases people have been putting
forward be solved without putting so much weight on LDPCs. I am for very simple LDPCs that act
simply like directories and then for an additional vocabulary to help explain what the consequences
of POSTing to an LDPC are, independent of the functionality of the LDPC itself. This would help
distinguish data the server is an charge of (metadata), and what the meaning of POSTing information
in an LDPC is going to be.

Henry


> 
> Richard
> 
>> 
>>> 
>>> Therefore, let's express the distinction the way information is expressed in RDF: in triples. (Or HTTP headers. Just not in a blank node vs URI distinction.)
>>> 
>>> Richard
>>> 
>>> 
>>> On 15 May 2013, at 23:17, Henry Story <henry.story@bblfish.net> wrote:
>>> 
>>>> 
>>>> On 15 May 2013, at 23:27, Richard Cyganiak <richard@cyganiak.de> wrote:
>>>> 
>>>>> On 15 May 2013, at 19:41, Henry Story <henry.story@bblfish.net> wrote:
>>>>>>>> [[
>>>>>>>> 3.  The value "self" signifies that the IRI in the value of the href
>>>>>>>> attribute identifies a resource equivalent to the containing
>>>>>>>> element.
>>>>>>>> ]]
>>>>>>>> 
>>>>>>>> http://tools.ietf.org/html/rfc4287#section-4.2.7.2
>>>>>>> 
>>>>>>> Does this imply that the IRI denotes an XML element?
>>>>>> 
>>>>>> The IRI denotes a resource whose representation is equivalent to the containing element.
>>>>>> The element need to be XML btw: it can be html, text, RDF or any other representation
>>>>>> for that matter. If you don't like that relation then it is easy to create a new one
>>>>>> that is more appropriate for us.
>>>>> 
>>>>> A relation - it would probably have to be a new one - with the semantics “fetch this URL to get a complete description of the subject” would address the use case, I think. It shouldn't matter whether the subject is blank though.
>>>>> 
>>>>>>> Nothing in RDF or in the definitions of said properties says anything about in-lining or completeness of descriptions. So if LDP says something about these things, without adding a new property or class or HTTP header, then surely it has added something to the semantics of RDF or of these properties.
>>>>>> 
>>>>>> Behaviorally it is equivalent.
>>>>> 
>>>>> No. Your proposal provides a distinction between “can be dereferenced” and “cannot be dereferenced”. That's not the distinction that's being asked for here. The relevant distinction here is: “server has provided everything it knows” versus “server has a URL where more information about the resource can be fetched”. These are completely different things.
>>>> 
>>>> Good then lets define and use that relation.
>>>> 
>>>>> 
>>>>>> You cannot retrieve the resource, so that is all you can know about the resource.
>>>>> 
>>>>> As I've said before, this statement is not true, because there can be many ways, including but not limited to sameAs, of inferring that the blank node is in fact a placeholder for some URI in the graph.
>>>> 
>>>> If you bring reasoning in then you have other serious problems with ldp:memberInlined. Namely how can you guarantee 
>>>> that the inlined members of two different resources don't interact in odd ways through reasoning too?
>>>> 
>>>> <> rdf:member <m1>, <m2>;
>>>> ldp:memberInlined <m1>, <m2> .
>>>> 
>>>> <m1> buying <jaguar> .
>>>> <m2> buying <jaguar> .
>>>> 
>>>> <jaguar> price [ euros 20000 ]
>>>> 
>>>> Now does both <m1> and <m2> have to contain the same price?
>>>> 
>>>> I am sure one could concoct thousands of other examples. Some of these inferences might
>>>> only be visible to reasoners at one level of owl, others at other stronger levels of owl.
>>>> Does the spec not have to now deal with all these levels of reasoning?
>>>> 
>>>> This does seem to make the case for limiting the type of relations on a LDPR to only metadata relations,
>>>> that is relations on an information resource which Erik Wilde has argued for in the past. But if you 
>>>> do that then the case for using blank nodes can be made even better.
>> 
>> Please consider the above.
>> 
>> 
>>>>> 
>>>>>> What is the Use Case you are trying to solve anyway? Perhaps that would help to be clear about it.
>>>>> 
>>>>> The use case is efficiency. If complete descriptions are inlined, clients would waste time and bandwidth by resolving member URIs. For example, think of an LDP server that manages an RDF vocabulary (with slash namespace). The server would probably present the entire vocabulary as a single RDF document with complete inline descriptions, as is customary for vocabularies. Does a generic LDP client that wants to retrieve the entire thing need to do 1 request or n+1 (where n is the number of terms in the vocabulary)?
>>>> 
>>>> what you really need is to express things in N3 with named graphs.
>>>> By restricting ourselves to Turtle or other simple RDF formats, we can get the 
>>>> same thing by using RDF literals.
>>>> 
>>>> <> rdf:member [ :title "An Order for a sanwich" ;
>>>>             :updated "2013-05-13..."^^xsd:dateTime;
>>>>             :content """
>>>>              @base ...
>>>>              @prefix ...
>>>> 
>>>>              <> :title "An Order for a Sandwich";
>>>>                     :primaryTopic _:x 
>>>>             _:x  a TunaSandwich
>>>>           """^^lang:Turtle
>>>>           ]
>>>> 
>>>> Here you'd know exactly what the content was, and you can use the updated relation
>>>> to see if you need to update the resource.
>>>> 
>>>> If people had spent more time earlier standardising N3 we'd certainly have a more
>>>> elegant solution. Perhaps this will spur those efforts.
>>>> 
>>>> 
>>>>> 
>>>>>> Do
>>>>>> we have a use case of inlined membership in the UCR ? http://www.w3.org/TR/ldp-ucr/
>>>>> 
>>>>> Good question.
>>>> 
>>>> Thanks.
>>>> 
>>>>> 
>>>>>>>> The RDF semantic sepc says that replacing a URI with  a bnode is equivalent. ( less info, but the 
>>>>>>>> truth value does not change).
>>>>>>> 
>>>>>>> This is incorrect, as I said earlier. Entailment is not equivalence.
>>>>>> 
>>>>>> You are splitting hairs here.
>>>>> 
>>>>> No, Henry, I am educating you so that you can speak on the topic more authoritatively.
>>>> 
>>>> Stop being pretentious please, it does not help us solve our problems.
>>>> 
>>>>> 
>>>>> All the best,
>>>>> Richard
>>>>> 
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>>> In RDF stands for Resource Description Framework. You can relate things to resources
>>>>>>>> by name, by description,  or both ( as many examples in the current spec show ).
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> In RDF you can always replace a URI with a blank node without affecting
>>>>>>>>>> the truth value of the graph.
>>>>>>>>> 
>>>>>>>>> (Nitpick: not true, as it can turn a false graph into a true one.)
>>>>>>>> 
>>>>>>>> ?? In the RDF Semantics simple entailment Rules section we have the following entailment rule
>>>>>>>> 
>>>>>>>> se2: uuu aaa xxx => _:nnn aaa xxx .
>>>>>>>> 
>>>>>>>> http://www.w3.org/TR/rdf-mt/#simpleRules
>>>>>>>> 
>>>>>>>> An entailment by definition does not change a truth into a falsehood.
>>>>>>> 
>>>>>>> But an entailment may change a falsehood into a truth. So it may change the truth value from false to true. Entailment is not equivalence. You already know this. I just pointed out that you spoke sloppily.
>>>>>> 
>>>>>> Is that relevant to this use case?
>>>>>> 
>>>>>>> 
>>>>>>> Richard
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Richard
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> The current spec is therfore consistent with
>>>>>>>>>> the proposal.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Richard
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 13 May 2013, at 17:25, Henry Story <henry.story@bblfish.net> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Hi, 
>>>>>>>>>>>> 
>>>>>>>>>>>> During today's teleconference discussing this issue I suddenly 
>>>>>>>>>>>> realised that there is a  futher solution to those presented here, which 
>>>>>>>>>>>> I think is both simpler and can be applied much more widely: that is to 
>>>>>>>>>>>> all linked data.
>>>>>>>>>>>> 
>>>>>>>>>>>> So first of all it turns out that there are good arguments for the use cases
>>>>>>>>>>>> of A and B/C . The current proposals end up requiring the creation of two
>>>>>>>>>>>> new relations. This is problematic because linked data consumers need to
>>>>>>>>>>>> know about these relations. That is a Linked Data Client instead of just having
>>>>>>>>>>>> to make the following query on an LDPC named ldpc
>>>>>>>>>>>> 
>>>>>>>>>>>> val members =  ldpc/rdf.member
>>>>>>>>>>>> 
>>>>>>>>>>>> It now has to also do something like the following
>>>>>>>>>>>> 
>>>>>>>>>>>> val members = if ( (ldpc/membersInlined).contains("true") )  
>>>>>>>>>>>>                       ldpc/ldp.memberInlined
>>>>>>>>>>>>                  else {
>>>>>>>>>>>>                      val local = ldpc/ldp.memberInlined 
>>>>>>>>>>>>                      val remote = (ldpc/rdf.member - local).map( _.follow )
>>>>>>>>>>>>                      local union remote
>>>>>>>>>>>>                   }
>>>>>>>>>>>> 
>>>>>>>>>>>> ( much more complex that this to tell you the truth )
>>>>>>>>>>>> 
>>>>>>>>>>>> What is problematic about this is that it would only work for LDPCs, and one could
>>>>>>>>>>>> easily imagine that each LDP service would develop its own version making code
>>>>>>>>>>>> unecessarily difficult.
>>>>>>>>>>>> 
>>>>>>>>>>>> But I have to explain the simple solution to make it clear why I can use "unecessarily 
>>>>>>>>>>>> difficult": the simple answer is that RDF already comes with the tools to make distinguish
>>>>>>>>>>>> nodes one can follow and nodes one cannot: the blank node! So I propose that for resources
>>>>>>>>>>>> where all the data is contained locally you do the following
>>>>>>>>>>>> 
>>>>>>>>>>>> <> a ldp:Container;
>>>>>>>>>>>> rdf:member [ atom:title "Atom Robots Run Amock" ;
>>>>>>>>>>>>                  atom:summary "Atom Robots having drunk a triple espresso semantic powerade....";
>>>>>>>>>>>>                  atom:content " ...." ; 
>>>>>>>>>>>>                  atom:id "http://news.example/2013/05/13/atomRobots"^^xsd:anyURI;
>>>>>>>>>>>>                  atom:updated "2013-05-13..."^^xsd:dateTime;
>>>>>>>>>>>>                ],
>>>>>>>>>>>>                [ atom:title "Semantic Revolution in the Blogosphere";
>>>>>>>>>>>>                  atom:summary "it all makes sense!";
>>>>>>>>>>>>                  atom:id "http://news.example/2013/05/12/semanticRevolution"^^xsd:anyURI;
>>>>>>>>>>>>                  ...
>>>>>>>>>>>>                ] .
>>>>>>>>>>>> 
>>>>>>>>>>>> So here it is no way to follow the LDPC members, and the ids are not URIs in use
>>>>>>>>>>>> either. If you do want to also allow people to follow the links you can use owl:sameAs or perhaps
>>>>>>>>>>>> the rel=self relation from atom
>>>>>>>>>>>> 
>>>>>>>>>>>> <> a ldp:Container;
>>>>>>>>>>>> rdf:member [ atom:title "Atom Robots Run Amock" ;
>>>>>>>>>>>>                  atom:summary "Atom Robots having drunk a triple espresso semantic powerade....";
>>>>>>>>>>>>                  atom:content " ...." ; 
>>>>>>>>>>>>                  atom:self <atomRobots>;
>>>>>>>>>>>>                  atom:updated "2013-05-13..."^^xsd:dateTime;
>>>>>>>>>>>>                ],
>>>>>>>>>>>>                [ atom:title "Semantic Revolution in the Blogosphere";
>>>>>>>>>>>>                  atom:summary "it all makes sense!";
>>>>>>>>>>>>                  atom:self <semanticRevolution>;
>>>>>>>>>>>>                  ...
>>>>>>>>>>>>                ] .
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Finally for members where the data should be followed first rather than later
>>>>>>>>>>>> 
>>>>>>>>>>>> <> a ldp:Container;
>>>>>>>>>>>> rdf:member <atomRobots>,  <semanticRevolution> .
>>>>>>>>>>>> 
>>>>>>>>>>>> # a bit of extra data for people arriving on this resource using simpler tools...
>>>>>>>>>>>> 
>>>>>>>>>>>> <atomRobots> atom:title "Atom Robots Run Amock" ;
>>>>>>>>>>>>                  atom:summary "Atom Robots having drunk a triple espresso semantic powerade....";
>>>>>>>>>>>>                  atom:updated "2013-05-13..."^^xsd:dateTime .
>>>>>>>>>>>> 
>>>>>>>>>>>> <semanticRevolution> atom:title "Semantic Revolution in the Blogosphere";
>>>>>>>>>>>>                  atom:summary "it all makes sense!" .
>>>>>>>>>>>> 
>>>>>>>>>>>> The advantage of this is that one can write clients that follow links automatically ( with 
>>>>>>>>>>>> cleverly built cashes to avoid fetching ontologies such as foaf or DC of course ) 
>>>>>>>>>>>> so that as far as possible they always  go to the source of the data, where the information
>>>>>>>>>>>> is defined. When a server does not wish this to happen the server can simply use the blank
>>>>>>>>>>>> node thereby simply stopping the possiblity of getting further information!  The atom:self type
>>>>>>>>>>>> relation or owl:sameAs then gives a way for the server to express that all the data is available
>>>>>>>>>>>> remotely at that location.  
>>>>>>>>>>>> 
>>>>>>>>>>>> This way we have an answer that works for all LDP resources and we can write generic
>>>>>>>>>>>> code without having to make special corner cases for each type of resource we come across.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Henry
>>>>>>>>>>>> 
>>>>>>>>>>>> On 30 Apr 2013, at 20:51, Arnaud Le Hors <lehors@us.ibm.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Looking back at what has been said on this issue, I see several possible paths forward: 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Option A: Richard's original proposal (without all the details): 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Add to ldp:Container a boolean property which, when true, indicates that a complete description of all the members is inlined in the container document. 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Option B: 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Add to ldp:Container a property ldp:memberInlined which indicates the members for which a complete description is inlined in the container document. 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Option C: 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Add a boolean property ldp:memberInlined which, when true, indicates that a complete description of that member is inlined in the container document. 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Option D: 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Add a repeatable HTTP Header, such as X-Cacheable-for, which when set to a member URI means that a complete description of that member is inlined in the container document. 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Here are some examples for each options: 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Option A: 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> # The following is the representation of
>>>>>>>>>>>>> #                  http://example.org/netWorth/nw1
>>>>>>>>>>>>> @prefix dcterms: <http://purl.org/dc/terms/>.
>>>>>>>>>>>>> @prefix ldp:      <http://www.w3.org/ns/ldp#>.
>>>>>>>>>>>>> @prefix o:       <http://example.org/ontology/>.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> <>
>>>>>>>>>>>>> a o:NetWorth, ldp:Container;
>>>>>>>>>>>>> ldp:membershipPredicate o:asset;
>>>>>>>>>>>>> o:asset <a1>, <a2>; 
>>>>>>>>>>>>> ldp:membersInlined true.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> <a1>
>>>>>>>>>>>>> a o:Stock;
>>>>>>>>>>>>> o:value 10000.
>>>>>>>>>>>>> <a2>
>>>>>>>>>>>>> a o:Bond;
>>>>>>>>>>>>> o:value 20000. 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Option B: 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> # The following is the representation of
>>>>>>>>>>>>> #                  http://example.org/netWorth/nw1
>>>>>>>>>>>>> @prefix dcterms: <http://purl.org/dc/terms/>.
>>>>>>>>>>>>> @prefix ldp:      <http://www.w3.org/ns/ldp#>.
>>>>>>>>>>>>> @prefix o:       <http://example.org/ontology/>.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> <>
>>>>>>>>>>>>> a o:NetWorth, ldp:Container;
>>>>>>>>>>>>> ldp:membershipPredicate o:asset;
>>>>>>>>>>>>> o:asset <a1>, <a2>; 
>>>>>>>>>>>>> ldp:memberInlined <a1>, <a2>.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> <a1>
>>>>>>>>>>>>> a o:Stock;
>>>>>>>>>>>>> o:value 10000.
>>>>>>>>>>>>> <a2>
>>>>>>>>>>>>> a o:Bond;
>>>>>>>>>>>>> o:value 20000. 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Option C: 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> # The following is the representation of
>>>>>>>>>>>>> #                  http://example.org/netWorth/nw1
>>>>>>>>>>>>> @prefix dcterms: <http://purl.org/dc/terms/>.
>>>>>>>>>>>>> @prefix ldp:      <http://www.w3.org/ns/ldp#>.
>>>>>>>>>>>>> @prefix o:       <http://example.org/ontology/>.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> <>
>>>>>>>>>>>>> a o:NetWorth, ldp:Container;
>>>>>>>>>>>>> ldp:membershipPredicate o:asset;
>>>>>>>>>>>>> o:asset <a1>, <a2>.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> <a1>
>>>>>>>>>>>>> a o:Stock;
>>>>>>>>>>>>> o:value 10000; 
>>>>>>>>>>>>> ldp:memberInlined true.
>>>>>>>>>>>>> <a2>
>>>>>>>>>>>>> a o:Bond;
>>>>>>>>>>>>> o:value 20000; 
>>>>>>>>>>>>> ldp:memberInlined true. 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Option D: 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> # The following is the representation of
>>>>>>>>>>>>> #                  http://example.org/netWorth/nw1
>>>>>>>>>>>>> @prefix dcterms: <http://purl.org/dc/terms/>.
>>>>>>>>>>>>> @prefix ldp:      <http://www.w3.org/ns/ldp#>.
>>>>>>>>>>>>> @prefix o:       <http://example.org/ontology/>.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> <>
>>>>>>>>>>>>> a o:NetWorth, ldp:Container;
>>>>>>>>>>>>> ldp:membershipPredicate o:asset;
>>>>>>>>>>>>> o:asset <a1>, <a2>.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> <a1>
>>>>>>>>>>>>> a o:Stock;
>>>>>>>>>>>>> o:value 10000.
>>>>>>>>>>>>> <a2>
>>>>>>>>>>>>> a o:Bond;
>>>>>>>>>>>>> o:value 20000. 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> HTTP Headers: 
>>>>>>>>>>>>> X-Cacheable-for: http://example.org/netWorth/nw1/a1 
>>>>>>>>>>>>> X-Cacheable-for: http://example.org/netWorth/nw1/a2 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Comments anyone? 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>>>>>>>>>>>> 
>>>>>>>>>>>> Social Web Architect
>>>>>>>>>>>> http://bblfish.net/
>>>>>>>>>> 
>>>>>>>>>> Social Web Architect
>>>>>>>>>> http://bblfish.net/
>>>>>>>> 
>>>>>>>> Social Web Architect
>>>>>>>> http://bblfish.net/
>>>>>> 
>>>>>> Social Web Architect
>>>>>> http://bblfish.net/
>>>> 
>>>> Social Web Architect
>>>> http://bblfish.net/
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 

Social Web Architect
http://bblfish.net/

Received on Saturday, 18 May 2013 10:37:42 UTC