|
Guillaume,
We just had a chat with Jad and think that if you have full control over the code, you might want to extend a Link class
to be an OrderedLink with an extra oslc:order property. This will allow you to get to a field on which you can sort. If there is enough push for it, we may extend the AbstractReifiedResource to support extended properties in Lyo 4.0
--
/Andrew
Guillaume,
I think I understand what you mean. What I tried to express is that you can't assume anything about the order of the following statements:
rc1 oslc_rm:elaboratedBy req1 .
rc1 oslc_rm:elaboratedBy req2 .
When you enumerate over 'Set<Requirement> getElaboratedBy()', you can't know the order.
But, as you said, you need to keep some order information. There are two ways:
1) You sort specifically by some property. E.g. when you get a set of requirements elaborating a given requirement, you use the Java Stream API I linked before to sort on the requirement's 'dcterms:title', for example.
2) Define an extra property for expressing order. You are free to reuse the 'oslc:order' property.
Example of the latter:
rc1 oslc_rm:elaboratedBy req1 .
rc1 oslc_rm:elaboratedBy req2 .
req1 oslc:order "1"^^xsd:integer .
req2 oslc:order "2"^^xsd:integer .
Now you can sort all of the requirements that elaborate 'rc1' by their 'oslc:order' property. Practically, you'd define a 'orderKey = new QName(OslcConstants.OSLC_CORE_NAMESPACE, "order")' and then do the sort of the set based on the value of
the following lambda: 'it -> it.getExtendedProperties().get(orderKey)'.
The problem in your case is that you just have a bare Set of URIs. Jad, Jim, any thoughts?
--
/Andrew
Hello,
most of requirement tools that I know used a multi level tree structure to represente data and not a list (ReqIf, Doors, R4J, ...).
Lyo Model is based 3 levels Tree (project, requirement collection, requirement). So if we want to present the tree without a view, just to let user browse and understand data has they already know it, we need to keep order and level. I already
have level in my system but I loose the order information just because the data structure doesn't keep order.
If I weel understand you, you don't want to keep the order. Because RDF don't want it by nature. Is that it ?
But it's force user to query a second time the server to get the order.
For exemple, I see this post, where doors user query twice time Doors with internal api to get the order after getting data from OSLC :
I am sorry, maybe we don't have the good approach. But I don't understand why OSLC must loose this information.
Because as OSLC client, it's interesting to show data as they really are in server.
I am really sorry, because my understanding of Lyo is maybe wrong ... For me this tools/ protocol help us to connect data between cross domain application.
Could you help me ? Must I use other approach ?
Le mar. 4 déc. 2018 à 11:46, Andrii Berezovskyi < andriib@xxxxxx> a écrit :
Guillaume,
Let me clarify a bit more as I dug up some notes. There are three places where ordering can be considered as far as OSLC Servers are concerned:
1) Usual GET/PUT OSLC requests (raw RDF inside the body).
2) OSLC Query results.
3) SPARQL results.
§1 Raw RDF does not have ordering guarantees on properties. Links:
"Information is represented by a set of RDF triples, often called a model. As it is a set, there is no ordering"
§2 The only place where we break RDF convention is the OSLC Query results, where the order of the returned results matters. The actual
spec says in [query-50] that ordered resources should come in the right order. However, it has been proposed to
change that to express ordering explicitly but the current spec allows [query-51] to satisfy this. Jim may have a different viewpoint on this.
§3 SPARQL results return ordered set of rows. However, we don't expect SPARQL to be used anywhere by default and don't have special code to handle it.
Ideally, I would like to generate methods like
Set<IResource> getSomeProperty();
void setSomeProperty(Collection<IResource> resources);
But this would require an incompatible change to the API and we don't want to break compatibility for little or no reason.
--
/Andrew
Hello Guillaume,
Thank you for inspecting this issue carefully! May I ask you why are you expecting any order to be preserved? Are you aware that RDF treats multiple resources not as a List but as a Set?
Because I would suggest to switch to a HashSet to make sure order is not preserved.
Hello,
I am using an OSLC Requirement Server with OSLC. And I see that requirement uses URI don't keep the order from OSLC Server because it's store in a TreeSet.
TreeSet use natural order comparator to sort element. But natural order have no sens for URI.
So I propose to use LinkedHashSet which keep the order provide by OSLC Server.
Can I provide a PullRequest for this ?
If you are ok, which the best way to do the PR : gerrit or github ?
Regards
_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/lyo-dev
_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/lyo-dev
_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/lyo-dev
_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/lyo-dev
|
