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