-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How should list ordering be preserved in R5? #76
Comments
List ordering option 2: parallel explicit index list. Similar to option 1, but using an explicit index using OLO or other conventions instead of a standard RDF list.
Pros:
Cons:
schema.org uses an explicit 1-based
|
List ordering option 3: Only use regular RDF lists This example assumes that we also change to eliminate the extra bnode and fhir:value, per issue #77 option 3b.
|
List ordering option 4: parallel indexed list, but using a separate attribute. Similar to option 1, but instead of putting the parallel index list under the same attribute, put it under an
Pros:
Cons:
|
Discussion on call on 2021-10-21:
An open question is whether the redundant information is worth it in this case, given that the indexed version will always be present. Todo: Ensure that it is explicitly stated somewhere that the indexes need to be in sequence, starting from 0 (in the event this applies to the selected model). |
Link to minutes: https://www.w3.org/2021/11/11-hcls-minutes.html#t01 |
In the last meeting, we discussed whether using native RDF lists would interfere with treating the RDF rendering as an OWL document. I think that may be the case: the OWL 2 Web Ontology Language
In order to use an OWL reasoner on the contents of lists we would need to treat |
Some previous discussions touching on use of
|
Notes on OWL compatibility with RDF lists: https://docs.google.com/document/d/1kNkP0EHfUiEj9GwO4NtzHXQD4kVTViphV0ngGfHBnBI/edit?usp=sharing |
Just a side proposal: What do you think of using rdf:bag and rdf:seq. |
As a medical student, I probably should evocate the significance of order in certain situations. |
Symptoms can change their characteristics according to the evolution of the condition:
|
That could be a possibility in theory, but the motivation behind this issue is to enable conventional RDF lists (a/k/a RDF Collections) to be used in FHIR RDF, using the Turtle short-hand syntax. |
Yes, the order of events is crucial in healthcare. However, from what I've seen, most of the time-ordered events that are recorded in medical records have individual timestamps on them anyway -- allowing them to be unambiguously ordered -- so they are usually stored as separate events rather than storing them as a list per se. However, some properties allow a list of entries to be provided -- such as a patient contact or address -- and the order of items in the list is sometimes used to indicate precedence. |
I don't think that helps. The prob is not the first/rest ladder, but instead the expression of axioms on properties in the |
Discussed on 04-Aug-2022, 09-Aug-2022, 11-Aug-2022 |
To summarize my view, I think we'd be losing more than we're gaining by switching to RDF lists, because:
Example JSON:
With RDF lists:
Without RDF lists:
|
I have seen the W3C discussions. I found https://lists.w3.org/Archives/Public/public-owl-wg/2008Jun/0070.html as a solution. |
To explain the proposal, there are slides proposed by Drummond at https://protege.stanford.edu/conference/2006/submissions/slides/7.1_Drummond.pdf. Please see the part about OWL lists. |
Thanks, @csisc , for finding that. David Wood and James Leigh also made a proposal at the 2009 W3C RDF Next Steps workshop to add ordered lists to RDF as a fundamental concept, instead of the makeshift first/rest ladder that RDF currently has for them. I personally think that ordered lists should be a fundamental concept in RDF, rather than continuing to try to retrofit onto a first/rest ladder. It is a blatant gap in RDF. To quote Manu Sporny (inventor of JSON-LD):
But I think RDF lists as a built-in type will have to wait until RDF 2.0. :) |
On today's call we reached consensus to go ahead with RDF lists in R5:
|
Done in R5. |
FHIR requires that item order be preserved in lists, but native RDF list support is terrible. How should FHIR RDF retain item ordering when a list is given?
Example JSON:
Option 0: Do nothing. Keep the R4 representation, which uses fhir:index to indicate the relative ordering of items in a list.
Example Turtle:
Note that if bnode and fhir:value are removed, per issue 77 option 3b, then fhir:value would still be needed for primitive list items, to attach the fhir:index:
Option 1: Set with parallel RDF list. See https://github.com/fhircat/fhir_rdf_validator/blob/master/tutorial/FHIRR5.md In this option, each JSON list is represented in RDF both as an unordered set of values and as an RDF list. Note that in this example, the outer set has only one item, so when it is repeated as a list, it looks almost identical.
Example Turtle:
Pros:
Cons:
The text was updated successfully, but these errors were encountered: