-
Notifications
You must be signed in to change notification settings - Fork 7
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
RDF to JSON should use @annotation, where possible #11
Comments
I see two things that can make this tricky:
Here's an idea:
Example: we start with: {
"<< << ex:a ex:b ex:c >> ex:d ex:e >>": {
"@id": { "@id": { "@id": "ex:a", "ex:b": {"@id": "ex:c"} }, "ex:d": {"@id": "ex:e"} },
"ex:f": [ { "@id": "ex:g" } ]
},
"<< ex:a ex:b ex:c >>": {
"@id": { "@id": "ex:a", "ex:b": {"@id": "ex:c"} },
"ex:d": [ {"@id": "ex:e"} ]
},
"ex:a": {
"ex:b": {"@id": "ex:c"}
}
} We find that the first entry has a match in the second entry, so we move it there as an annotation: {
"<< ex:a ex:b ex:c >>": {
"@id": { "@id": "ex:a", "ex:b": {"@id": "ex:c"} },
"ex:d": [ {"@id": "ex:e",
"@annotation": { "ex:f": [ { "@id": "ex:g" } ] }
} ]
},
"ex:a": {
"ex:b": {"@id": "ex:c"}
}
} and then we find that the (originally) second entry has a match in the (originally) third entry, so we move it there as an annotation: {
"ex:a": {
"ex:b": {"@id": "ex:c",
"@annotation": {
"ex:d": [ {"@id": "ex:e",
"@annotation": { "ex:f": [ { "@id": "ex:g" } ] }
} ]
}
}
}
} |
That's essentially the same method I had been thinking about, although I think we can simply reverse sort by length to get the same effect. Of course, there may be some corner cases where annotations are used at the beginning and ending of a chain, but not in the middle that could be tricky. Thanks for thinking this through! |
If by "length" you mean the string-length of the key, I find this too brittle.. A simple triple with a very long term may be longer than a deeply nested triple with short terms. Idea: could we encode the depth of a triple in their key in the node map? That way, the sorting would be much easier ;-) |
My reasoning is that the goal is to look for more deeply embedded triples before more shallowly, and that terms that might be chosen before deeper embedded terms would not interfere. It's possible that subject- vs object- embedding could be fooled, though. Did you have some examples of where this would go wrong?
Yes, we could come up with an algorithm for creating the key, which would get back a measure of the depth of embedding in addition to the canonicalized form, and that would probably work okay. |
yes, we agree on that
Oh, I see it now! Of course, length is not a good proxy for depth in general, that is not a problem. We are actually only interested in the partial order "contains", for which length is a good proxy! So yes, key length is much simpler, and doing the job perfectly. I stand corrected 👏 |
The existing algorithm only uses embedded nodes.
The text was updated successfully, but these errors were encountered: