Re: Issue-37: Ontological Modelling

On 21 Jan 2013, at 19:07, Ashok Malhotra <> wrote:

> OK.  Let's add a SHOULD.    Something like "If a member of an Aggregation is deleted it SHOULD
> first be removed from all the Aggregations it participates in"

Is this something you want for all resources mentioned in all LDPRs, or is it that you are thinking
of LDPAs as very special things? Ie: do you think that any resource that appears in an LDPR/A SHOULD
be removed from that LDPR/A before being deleted? 

Because this seems to be going against a very deep Web Architectural assumption. Tim Berners-Lee's
big change over other hypertext systems was to NOT require the web to be consistent. As the story
goes ( other members of the group may have pointers to some literature ) all previous hypertext
systems were very concerned to have consistency across the hypertext database. But in a global
decentralised model, where not all resources may be "conscious" of the other resources mentioning
them it is impossible to demand such general consistency. 

The most you can ask for is local consistency. You could do this by defining an agent that kept information
over a certain domain locally consistent. 

  ldpx:ConsistencyAgent rdfs:subclassOf foaf:Agent .

and define a relation such as consistentOver allowing you to say:

  <> a ldpx:ConsistencyAgent;
      consistentOver [ regex "*" ] .

I think once you have such a notion it is possible to state consistency of
deleting LDPAs owned by that agent in such a way. 

One could then also define a politeConsistentAgent as one that would try to notify
as soon as possible any agent it knew to to be using a resource it deleted.

but my guess is that that is out of scope, and furthermore it is going to be
a lot of work to define that well.

> Re. the other issue about whether Aggregations and Collections are separate classes or flavors
> of the same class, let's hold that question and see what we get from other WG members.
> All the best, Ashok
> On 1/21/2013 9:53 AM, Henry Story wrote:
>> On 21 Jan 2013, at 18:27, Ashok Malhotra<>  wrote:
>>> Henry:
>>> " Similarly deleting updating or altering resources that are members of an ldp:Aggregtion does not have any required implication on an ldp:Aggregation."
>>> If you delete a member of an Aggregation, shouldn't you first remove it from the Aggregation.
>>> Otherwise, the Aggregation will contain a null pointer.
>> I think indeed that one could have a SHOULD there. But what if TimBL deletes me from his
>> foaf:knows? He can't also change my foaf:Profile ... ( assuming my foaf:Profile were
>> an ldp:Aggregation... )
>> There may be a way we can express this such that it is recommended that services
>> do keep their data consistent where possible...
>>> One other point, and this a matter of modelling philosophy.  In your formalism, Collections and Aggregations
>>> are distinct classes and you cannot convert one to the other.
>> I don't think this is a question of modelling philosophy here. I did not start with them
>> as distinct. Rather I came to the conclusion that they were.
>> That is why I added that to it's own space with an argument:
>>> If we distinguished Collections and Aggregations
>>> by the value of an attribute then you could easily change the value of the attribute and convert one to the other.  Is this important?
>> I think you mean when you speak of attributes you mean to distinguish them like this:
>>   <container/>  a ldp:Container .
>>   <container/?aggreg>  a ldp:Aggregation .
>> right? But then you have two different resources - so there is no overlap.
>>>  Perhaps.
>>> Or, you could have convert operations that change one class to another.
>> I am not sure what you mean by convert. I suppose a timeslice of a resource
>> could be an LDPC, then another non-overlapping timeslace could be an LDPA,
>> though this should be highly discouraged, as you would be confusing clients
>> that might have out of sync information about your resource, and do the wrong
>> thing.
>> If you think about it most file systems have the same non overlapping semantics.
>> A directory in most file systems can NEVER be a file. Note that I did not come
>> to this conclusion via an argumentation from file systems though.
>>> All the best, Ashok
>>> On 1/21/2013 8:54 AM, Henry Story wrote:
>>>> I added to the wiki for Issue-37 an section which tries to give the
>>>> first steps towards modelling LDP using ontologies.
>>>> RDF is a development of logic, and logic was designed by Frege
>>>> according to Robert B. Brandom ( Making it Explicit ) to make
>>>> presuppositions we have explicit. By making it easy to trace
>>>> the consequences of a statement one can reason about them
>>>> much more carefully.
>>>> Perhaps this can be then used to build the ldp ontology
>>>> which needs to be published in the LDP namespace.
>>>> Currently it seems that we can start distinguishing resources
>>>> described by LDP by what types of HTTP operations they allow -
>>>> which is not surprising since we are building a protocol. Since
>>>> HTTP operations directed at one type of resource don't have
>>>> the same meaning as when directed at another type or resource
>>>> eg HTTP POST of a Graph on an LDPC and on an LDPR, this does
>>>> seem to be useable to show that these are not overlapping
>>>> classes.
>>>> 	Henry
>>>> Social Web Architect
>> Social Web Architect

Social Web Architect

Received on Monday, 21 January 2013 19:01:57 UTC