Re: ldp-ISSUE-73 (rdf:member): LDPCs to list all their rdf:member [Linked Data Platform core]

On 24 May 2013, at 00:18, Roger Menday <roger.menday@uk.fujitsu.com> wrote:

> 
> Henry,
> 
> I think I understand why you want this. For me, if I need to find out about the Bugs in the BugTracker, I'm going to ask the BugTracker. I don't need to go to the container. 
> 
> What will happen in the case of combined LDPR and LDPC (where the membershipPredicate is present, but the membershipSubject is not). If the members follow the bad modelling style, then this means duplicated triples (I think) ...

It is not bad modelling style if your relation allows the relata to be Information Resources. We should
look at the case where that is so, and not consider bad modelling here.

If your LDPC has neither membershipSubject nor membershipObject relations, then your relation :arrow
will relate just your LDPC to the same members. It is quite likely then that 

 :arrow rdfs:subPropertyOf rdfs:member .

I am currently arguing that we should not be requiring reasoning, so that you will have duplicates.
If rdfs reasoning were required of your clients then you would only need to write out the :arrow relations.
If owl reasoning were required then you could get even more flexibility.

It seems to me that this initial LDP spec was trying to make no assumptions on reasoning, so you'd
either have to duplicate the relations or model your case differently.

The most useful case I can make for using a relation that is a subProperty of ldp:member is to express
that the domain of the relation  is of some type, say a foaf:PersonalProfileDocument. We could define this
realtion thus

:profile a rdf:Property;
    rdfs:subPropertyOf rdf:member;
    rdfs:range foaf:PersonalProfileDocument .

then a client would know that each of the members of the LDPC were a certain type of
document.  But that could also be modelled by just saying so for each content.

<> rdf:member <profile1> .
              <profile1> a foaf:PersonalProfileDocument .

Or just by specifying the collection as just containing certain types of profiles.

<> a ldp:Container, :PersonalProfileContainer .

How to automate the :PersonalProfileContainer type in a machine readable way is what the
RDF-Validator group will be working on https://www.w3.org/2012/12/rdf-val/Overview.php
 
Anyway, there is not much one can do about this. Either you accept inferenceing
and you get more power but you require more of your clients, or you don't require
inferencing and you need to write things in more detail.

I think that in the case of LDPC membership, this is going to be so basic a 
tool that you don't really want to put your heavy duty reasoning pieces in there.
Think of the LDPC as a filesytem directory. Those things need to last for very long
times: so their APIs are very simple and robust. You don't try to put clever reasoning
in a directory data structure. You put that in the files you place in the directory:
such as for example prolog files. There you can require any amount of reasoning you 
wish.


Henry

> 
> regards,
> Roger
> 
> 
> 
>> ldp-ISSUE-73 (rdf:member): LDPCs to list all their rdf:member [Linked Data Platform core]
>> 
>> http://www.w3.org/2012/ldp/track/issues/73
>> 
>> Raised by: Henry Story
>> On product: Linked Data Platform core
>> 
>> An LDPR MUST/SHOULD list all the resources that were created in it with a POST as rdf:member .
>> That is doing a GET on the LDPC should return a list of members. These members are the HTTP resources that are GETable, PATCHable, POSTable, DELETEable .
>> 
>> Advantages:
>> - a client can easily find out all the members of an LDPC by GETing it and querying the returned representation with some query  that is the equivalent of the SPARQL
>>      SELECT ?member WHERE { <> rdf:member ?member } 
>> - the client does not need reasoning to find out what the members are
>>    ( currently it seems to require some ldp:membershipProperty relation to find out what the member is )
>> - LDPRs that are not LDPCs don't get lost after creation. An admin client can easily find out all the members. ( currently LDPRs may be listed on a remote resource for which one needs to know the LDPCs it came from and that it had a ldp:membershipSubject . The same issue would be true for an ldp:membershipObject . )
>> - the LDPC is a good place to add metadata on the LDPR created such as title, update time, acl resources, ...
>> 
>> 
>> 
> 

Social Web Architect
http://bblfish.net/

Received on Thursday, 23 May 2013 23:00:01 UTC