Re: Issue-37: Ontological Modelling

On 21 Jan 2013, at 18:27, Ashok Malhotra <ashok.malhotra@oracle.com> 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:

   http://www.w3.org/2012/ldp/wiki/ISSUE-37#Lemmas


> 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.
>> 
>>   http://www.w3.org/2012/ldp/wiki/ISSUE-37
>> 
>> 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
>> http://bblfish.net/
>> 
> 

Social Web Architect
http://bblfish.net/