Re: Issue-89, proposal 3: Duplication of triples & inferencing

On 13 Dec 2013, at 22:04, Steve Speicher <sspeiche@gmail.com> wrote:

> I was trying not to start a discussion on what is good or bad example in the primer but trying to leverage the basic idea.
> 
> To be very clear, I believe the only thing we are discussing here is that when a server provides a ldp:DirectContainer representation, whether it MUST include in that representation all the triples that have ldp:xyz in them.  Which would double the number of "membership triples", from spec definition.
> 
> We have deployed a number of products that follow a pattern on how they expose resources from a container/collection thing.  I think we've established that.  To boil down to the simplest form, it really looks like:
> 
>  <bugs/> a bt:BugCollection;
>       bt:hasBugs <1>, ...., <300000>.

[[ aside for Primer writers:
minor tweak. Your <1>, ...., <30000> are information resources, so they are documents. And so your 
repository is one of bug reports. Bug Reports are things I imagine can change from being bugs, to being feature 
requests etc... Bugs themselves on the other hand can be duplicates of other bugs. So you can have less bugs than 
bug reports.  Furthermore bt:hasBugs sounds like a relation from one to many, whereas in RDF it is a relation from
one to one - so the relation should really be bt:hasBugReport . And then finally the hasBugReport, sounds like the
"has" is trying to relate a product to a bug. One says "a product has a bug" and a "collection contains a bug report".
So if we can translate this to something that is less likely to mislead the readers of our Primer, we should have this:

   <bugs/> a bt:BugReportCollection;
       bt:containsBugReport <1>;
        ....; 
       bt:containsBugReport <300000> .

( I spent some time thinking about this when I was at Sun Microsystems btw https://code.google.com/p/baetle/ )
]] 

> 
> This is it.  My tools know how to operate on this, they know how to index it and we have various ways to query on it.

Are you allready publishing your bugs in RDF, or are those in an SQL (or other) database?
Are your tools interacting in RDF or are they interacting through some other means?
If in RDF is the data allready visible?

Because if the issue is with allready published RDF resources then the use case is:
How does one add to allready published RDF resources LDP capabilities?
But then we should perhaps look more widely at the problem, by considering widely deployed
resources to see how they would need to be adapted.

> 
> It works much like the DirectContainer.  For my server to comply with ldp:DirectContainer it would only have to add to the representation these triples:
> 
> <bugs/> a bt:BugCollection, ldp:DirectContainer;
>     ldp:containerResource <bugs/>;
>     ldp:containsRelation bt:hasBug;
>     bt:hasBugs <1>, ...., <300000>.
> 
> Only adds 3 triples.  If I were to be forced to emit ldp:xyz, I would need to add 300,003 triples [1]. Which is unnecessary in this case since you can determine ldp:xyz from.  I have not heard a convincing reason I why we should force this in the specification.
> 
> From what I see:
> We all agree on ldp:SimpleContainer -- done

yes.

> We generally agree on ldp:DirectContainer approach, though we differ in which way triples should be inferred (if I can say inferencing).  I don't even have a problem saying it can work in either direction, if you omit ldp:xyz it can be inferred...if you omit domain supplied membership predicate then ldp:xyz can be inferred.

so the other way of writing this would be:

   <bugs/> a bt:BugReportCollection, ldp:DirectContainer;
       ldp:containerResource <bugs/>;
       ldp:containsRelation bt:containsBugReport;
       ldp:contains <1>;
        ....; 
       ldp:contains <300000> .

In some way it is allready a serious step forward that we are settling on the ldp:container* relations
as being inferential relations. I was not quite sure myself about this. Because when the issue was brought
up as to what should happen if the ldp:container* relations change it was not agreed that all the 
bt:containsBugReport triples also need to be changed.
see ISSUE-87 https://www.w3.org/2012/ldp/track/issues/87

That left it open that the ldp:container* relations are in fact rules that are only applied on creation
( though a POST ) or that were there before hand. To see this you need to consider these three cases:

(1) If the rule is from "membership triples" to ldp:contains

CONSTRUCT { ?subject ldp:contains ?ldpr }
WHERE{
  { ?ldpc a ldp:DirectContainer;
          ldp:containerResource ?subject;
          ldp:containsRelation ?predicate.    
    ?subject ?predicate ?ldpr. 
  } 
   UNION 
 {
     ?ldpc a ldp:DirectContainer;
           ldp:containerResource ?object;
           ldp:containedByRelation ?predicate.         
     ?ldpr ?predicate ?object .
  }
}

then it follows immediately that changing the ldp:container* resource
requires changing all the ?a ?predicate ?b relations. ( Which goes 
against resolution of ISSUE-87 ), since otherwise the LDPC would go
from having a number of ldp:contains relations to having none.

(2) If on the other hand the rule is the other way around, from 
ldp:contains to "membership triples" such as:

CONSTRUCT { ?subjet ?predicate ?object }
WHERE { 
 { ?ldpc a ldp:DirectContainer;
          ldp:containerResource ?subject;
          ldp:containsRelation ?predicate;   
          ldp:contains ?ldpr. 
    BIND (?ldpr AS ?object)                            
  } 
   UNION 
  {
     ?ldpc a ldp:DirectContainer;
           ldp:containerResource ?object;
           ldp:containedByRelation ?predicate;         
           ldp:contains ?ldpr. 
   BIND (?ldpr AS ?subject)                            
  }
}

then of course nothing needs to be changed in the container
when the ldp:container* relations are changed, since all the other
relations are automatically inferred. So it seems this 
type of inferencing is closer in line with resolution of ISSUE-87 .

(3) If finally the rule is one such as in (2) above, but with the
restriction that is applied only on POSTing to the container, ie. 
it is a  consequence of the user POSTing there, but not one that
can be added inferentially later then

 • it is very likely that you SHOULD not change the semantics of 
   the "membership triples"  that were created,
 • you MUST publish both the "membership triples" and the ldp:contains
   relations

This is also in line with the resolution of ISSUE-87.

Henry Story



> 
> - Steve
> 
> [1] - https://jazz.net/products/rational-team-concert/whats-happening#activity  (Information about hosted product with over 300,000 bug entries)
> 
> 

Social Web Architect
http://bblfish.net/

Received on Saturday, 14 December 2013 13:01:48 UTC