Comments (5)
I see two things that can make this tricky:
- the annotating triple may be encountered before the asserted annotated triple, so this would need to be done in a second phase
- annotations themselves can be nested.
Here's an idea:
- first generate the node maps normally (using embedded nodes)
- for each node map (corresponding to a named graph or the default graph):
- look for all subjects that are embedded nodes, and sort them by decreasing "depth" in
annotation_candidates
- for each embedded node
en
inannotation_candidates
- search the node map for the corresponding asserted triple
- if found, move the
en
entry of the node map as an@annotation
(without its@id
)
- look for all subjects that are embedded nodes, and sort them by decreasing "depth" in
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" } ] }
} ]
}
}
}
}
from json-ld-star.
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!
from json-ld-star.
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.
If by "length" you mean the number of atomic terms, then yes, it might be a good proxy for depth, but is that much easier to check.
Idea: could we encode the depth of a triple in their key in the node map? That way, the sorting would be much easier ;-)
from json-ld-star.
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?
Idea: could we encode the depth of a triple in their key in the node map? That way, the sorting would be much easier ;-)
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.
from json-ld-star.
My reasoning is that the goal is to look for more deeply embedded triples before more shallowly,
yes, we agree on that
and that terms that might be chosen before deeper embedded terms would not interfere
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 👏
from json-ld-star.
Related Issues (15)
- Broken link: https://github.com/json-ld/json-ld-bp/
- Allow annotations on list object HOT 4
- Make `rdfstar` an multiple-choice option rather than a flag HOT 7
- Expansion Algorithm: step 13.4.14
- Using `@annotation` on a `@type` HOT 15
- allow `"@annotation": "<IRI>"` in term definition HOT 3
- allow `"@type": "@triple"` or something similar? HOT 4
- W3C REC / JSON-LD 1.2/2.0 HOT 5
- are multiple triples forbidden in `@id`? HOT 1
- new container type leveraging RDF-star to encode order HOT 6
- rename "embedded node"
- Reverse properties in embedded nodes HOT 1
- Keeping quoted triples sharing subject within one node object
- Figure out restrictReferences on terms
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from json-ld-star.