Do you suggest that the x:index values would be returned in the description of the member? I don't think this works. The same member can occur at different positions in different containers. So this would only work if the triple is inlined in the container/page description. And how do clients know that they shouldn't consider the x:index value as part of the member's description? Richard On 2 Apr 2013, at 19:37, Nandana Mihindukulasooriya <nmihindu@fi.upm.es> wrote: > > > > On Tue, Apr 2, 2013 at 8:34 PM, Nandana Mihindukulasooriya <nmihindu@fi.upm.es> wrote: >> Hi, >> >> On Tue, Apr 2, 2013 at 8:02 PM, Ashok Malhotra <ashok.malhotra@oracle.com> wrote: >>> >>> On 4/2/2013 1:47 PM, Wilde, Erik wrote: >>>> why should order always be a function of some naïve ordering on a visible >>>> facet? >>> I'm not saying that. I'm saying that data-based ordering should be allowed as an option. >> >> +1. >> >> I think there are valid use cases for both scenarios. I think Raul's proposal can be used for explicit ordering by introducing an index (and there might be other intuitive ways). For example, >> >> <container> ldp:order _:l1 . >> _:l1 rdf:first _:event_2012-12-01 . >> _:l1 rdf:rest _:l2 . >> _:l2 rdf:first _:event_2013-01-14 . >> _:l2 rdf:rest _:l3 . >> _:l3 rdf:first _:event_2013-03-04 . >> _:l3 rdf:rest rdf:nil . >> >> IIUC, above can be represented something like > > I meant > > <container> ldp:containerOrder _:order . > _order ldp:containerSortPredicate x:index ; > ldp:ldp:containerSortOrder ldp:ascending . > _:event_2012-12-01 x:index 1 . > _:event_2013-01-14 x:index 2 . > _:event_2013-03-04 x:index 3 . > > Best Regards, > Nandana
Received on Wednesday, 3 April 2013 09:28:38 UTC