Re: Issue-37: Ontological Modelling

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"

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<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/
>

Received on Monday, 21 January 2013 18:07:56 UTC