- From: Steve Speicher <sspeiche@gmail.com>
- Date: Sun, 15 Dec 2013 10:14:33 -0500
- To: Henry Story <henry.story@bblfish.net>
- Cc: Arnaud LeHors <lehors@us.ibm.com>, Linked Data Platform WG <public-ldp-wg@w3.org>
- Message-ID: <CAOUJ7Jq_7Kk0k5Qj+Q62rEGN8-SXzF3YL9qvOpe=gEW7GH_uiA@mail.gmail.com>
On Sat, Dec 14, 2013 at 8:01 AM, Henry Story <henry.story@bblfish.net>
wrote:
>
>
> 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?
Answer is yes to both. We pretty much have any configuration you can think
of. Some that are RDF at its core. Some that are in SQL. Some that are
both. Some that are in a proprietary database technology.
> Are your tools interacting in RDF or are they interacting through some
other means?
I'm not sure what you asking. Yes clients interact with the RDF. There
are many other interfaces to the servers that manipulate the data: admin
interfaces, user interfaces, etc.
> If in RDF is the data allready visible?
Yes, if I understand the question. Not sure what visible means in this
context. A client can make a GET request for RDF, it sees the data
expressed in the RDF representation it receives.
>
> 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 don't quite get this statement. This is how the spec has worked from the
beginning, to be clear, and we are not settling on anything new in this
regard. You could always infer the relations from the ldp:membership*
relations, we just relabeled them ldp:containe* relations to help with
comprehension.
>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.
No, the resolution says it is server-defined and we don't say anything in
the spec. I'm not sure how you came to this conclusion. Servers can a)
reject requests to change ldp:containe* relations b) accept them and do the
right thing.
>
> (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 .
So I agree, it would be easier for a server to handle such a change this
way if it accepted a change to ldp:containe* but don't require this to be
the only way.
>
> (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
I'm still not convinced this is a MUST as you showed in (1) how one could
infer it.
>
> This is also in line with the resolution of ISSUE-87.
It is good to hear we seem to be aligned on basic concepts but just
narrowing in on some the details to tighten the spec
- Steve Speicher
>
> 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 Sunday, 15 December 2013 15:15:01 UTC