Re: How to find the members of an LDPC?

On 11/8/13 11:45 AM, Henry Story wrote:
> On 8 Nov 2013, at 17:16, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>
>> On 11/8/13 10:53 AM, Alexandre Bertails wrote:
>>> I would even argue that it should be defined outside of LDP core,
>>> probably in a different spec that builds on top of LDP, as people
>>> expect LDP to just define a simple protocol. That's basically the
>>> approach taken by the people working on WebID and WebACL: there is no
>>> circular dependency with LDP.
>>>
>>> Alexandre.
>> +1
> I think we need to think about this more carefully. If something like
> what I proposed in "volunteering for the army" [1] is going to be
> possible at some point in the future, then the basis for this needs to
> be settled now. For otherwise we may end up with a lot of clients that
> go POST things everywhere without looking at the consequences of their
> POSTing action. And then it will be impossible to add this feature later.
>
> So we need the current clients to allready understand some relation such
> as ldp:contractualBinding ( other possible names would be
> ldp:bind, ldp:postConsequence, ... ) so that when a client sees an LDPC
> with such a relation it will know NOT to post if it does not understand
> the meaning of it.
>
> The advantage of this is that one can start with something like the current
> proposal
>
> <> a ldp:Container;
>      ldp:contractualBinding [ ldp:subject <../card#me>;
>                 ldp:predicate foaf:knows;
>                 ldp:rangeSelector foaf:primaryTopic ] .
>
> and the blank node can then later be filled in by much more
> advanced languages that future standards will want to develop.
> Perhaps something in the future that will look like this
>
> <> a ldp:Container;
>      ldp:contractualBinding """
>         CONSTRUCT { <../card#me> foaf:knows ?t }
>         FROM CREATED
>         WHERE {
>             <> foaf:primaryTopic ?t
>         }"""^^future:language
>
> I am not saying this needs to be developed now. But if clients built now
> know not to POST into a container where they don't understand the contractual
> obligation, then this would be future proof.
>
> I suppose the other solution would be in the future to create an
> ldp:ContractualContainer that is a superclass of ldp:Container .
>
> Just a thought....
>
> Henry
>
> [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Nov/0022.html

I don't have an issue with:

<> a ldp:Container;
     ldp:contractualBinding [ ldp:subject <../card#me>;
                ldp:predicate foaf:knows;
                ldp:rangeSelector foaf:primaryTopic ] .

I like reification, and feel its got a bum wrap due to poor understanding. Yes, statements have implications etc..

Our fundamental challenge is that getting this accepted will be protracted. Maybe, just maybe, if the ldp:contractualBinding relation fully described in a vocabulary (in natural language using the rdfs:comments relation), its implications and intent could be easier to understand by others i.e., that statements have implications and consequences, and these do matter in design that's based on a little amount (at the very least) of machine-comprehensible semantics.

At the same time, we might end up living with superfluous relation implications in LDP (due to its focus) which then get rectified (in a complimentary manner) by efforts elsewhere, as Alexandre suggests.


Kingsley


>
>>
>> -- 
>>
>> 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
>>
>>
>>
>>
>>
> Social Web Architect
> http://bblfish.net/
>
>
>


-- 

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