ISSUE-14: Include clarifications about ordering in BPC representations
BPC representation ordering
Include clarifications about ordering in BPC representations
- State:
- CLOSED
- Product:
- Linked Data Platform Spec
- Raised by:
- Raúl García Castro
- Opened on:
- 2012-10-02
- Description:
- "5.3.7 BPC servers may represent the members of a paged BPC in a sequential order. The order must be specified using the bp:containerSortPredicates predicate whose subject is that of the page and object is a list of BPC ordinal predicates. The default ordering is ascending."
5.3.7 says that the default ordering is ascending. How can be other orderings specified?
Furthermore, in an RDF representation, the order of triples is meaningless.
Something about this should be said here since, in that case, the client would be the one that interprets the representation provided by the server in order to generate the ordered list.
- Related Actions Items:
ACTION-43 on Steve Speicher to Draft a use case for container ordering - due 2013-03-20, closed- Related emails:
- LDP Rec (from eric@w3.org on 2015-02-20)
- Re: ISSUE-58: the simple solution to inlined membership (from henry.story@bblfish.net on 2013-05-15)
- Re: ISSUE-58: the simple solution to inlined membership (from sspeiche@gmail.com on 2013-05-14)
- Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core] (from ashok.malhotra@oracle.com on 2013-04-05)
- Re: Trying to close ISSUE-14 (from Erik.Wilde@emc.com on 2013-04-03)
- Re: Trying to close ISSUE-14 (from sspeiche@gmail.com on 2013-04-03)
- Re: Trying to close ISSUE-14 (from Erik.Wilde@emc.com on 2013-04-03)
- Re: Trying to close ISSUE-14 (from nmihindu@fi.upm.es on 2013-04-03)
- Re: Trying to close ISSUE-14 (from richard@cyganiak.de on 2013-04-03)
- Re: Trying to close ISSUE-14 (from richard@cyganiak.de on 2013-04-03)
- Re: Trying to close ISSUE-14 (from rgarcia@fi.upm.es on 2013-04-03)
- Re: Trying to close ISSUE-14 (from nmihindu@fi.upm.es on 2013-04-02)
- Re: Trying to close ISSUE-14 (from Erik.Wilde@emc.com on 2013-04-02)
- Re: Trying to close ISSUE-14 (from nmihindu@fi.upm.es on 2013-04-02)
- Re: Trying to close ISSUE-14 (from ashok.malhotra@oracle.com on 2013-04-02)
- Re: Trying to close ISSUE-14 (from Erik.Wilde@emc.com on 2013-04-02)
- Re: Trying to close ISSUE-14 (from ashok.malhotra@oracle.com on 2013-04-02)
- Re: Trying to close ISSUE-14 (from Erik.Wilde@emc.com on 2013-04-02)
- Re: Trying to close ISSUE-14 (from sspeiche@gmail.com on 2013-04-02)
- Trying to close ISSUE-14 (from rgarcia@fi.upm.es on 2013-04-02)
- ACTION-43 Draft use case for ordering (from sspeiche@gmail.com on 2013-03-25)
- Re: Review and Comments for Linked Data Platform FPWD (from david@3roundstones.com on 2013-03-05)
- Re: Review and Comments for Linked Data Platform FPWD (from sspeiche@gmail.com on 2013-03-04)
- ldp-ISSUE-14 (BPC representation ordering): Include clarifications about ordering in BPC representations [Linked Data Platform core] (from sysbot+tracker@w3.org on 2012-10-02)
Related notes:
Arnaud's option A
---------
1. remove the two types of container AggregateContainer and
CompositeContainter, leaving the only kind of container to be
ldp:Container
2. specify that on deleting a container LDP servers MUST delete the
container and MAY delete member resources (typically to satisfy internal
requirements).
So if I have:
<> a ldp:Container;
rdfs:member <a>.
and I create <b> using POST to the container, I end up with:
<> a ldp:Container;
rdfs:member <a>, <b>.
When I delete the container, the container gets deleted, and <a> and <b>
MAY get deleted.
3. Defer adding an operation that let's a client request a recursive
delete to a future version of LDP, and do one of the following:
---------
option B
---------
1. remove the two types of container AggregateContainer and
CompositeContainter, leaving the only kind of container to be
ldp:Container
2. add that on creating a new member resource using POST, LDP servers
SHOULD add a triple a la : <> ldp:contains <newly_created_resource> if the
resource will be deleted when the container is deleted. Note that this is
in addition to adding the appropriate ldp:membershipPredicate or
ldp:membershipPredicateInverse triple to the container representation as
currently required.
3. specify that on deleting a container LDP servers MUST delete the
container and member resources listed as contained via ldp:contains, and
MAY delete other member resources (typically to satisfy internal
requirements).
So if I have:
<> a ldp:Container;
rdfs:member <a>.
and I create <b> using POST to the container, I end up with:
<> a ldp:Container;
rdfs:member <a>, <b>;
ldp:contains <b>.
When I delete the container, both the container and <b> get deleted. <a>
MAY be deleted.
4. Defer adding an operation that let's a client request a recursive
delete to a future version of LDP:
-------------
Resolution: Close ISSUE-14, saying an LDPC server can indicate to a client the ordering of members in a container page using an ldp:containerOrder property. This property has as range a list of resources with two properties: (a) ldp:containerSortPredicate, which defines the property used for sorting; (b) ldp:containerSortOrder, which defines the ordering (ascending or descending) and is optional, (c, etc.) collation, and others.
See https://www.w3.org/2013/meeting/ldp/2013-05-06#resolution_2
Display change log