Closed giuseppefutia closed 9 years ago
Hi Giuseppe,
Best is to think of covering the graph you have at hand from outside in. So first we create predicateMatchers for all leafes (red in your graphic). Second we create combineMatchers where we have multiple leafes on one node (e.g. a Place), next we use linkMatchers to go from the start resource (here an Event) to the intermediary nodes (e.g. an Organization, a Place) and eventually even more linkMatchers (to go from a Place to an Address). All these linkMatchers can again be grouped by a combineMatcher. This finally ends in one big structure which you can build a template for (better you build sub-templates for the smaller structures and combine them to the higher template).
That is the approach. A working example of a linkMatcher with combineMatcher you find in the dbpedia.exascale.info (try Fribourg, where we have dbpedia-owl:neighboringMunicipality attributes). If you can provide me with an example graph I try if time allows to show it in more detail.
Hint: There is right now a known issues on the linkMatcher if you describe the matcher in triple form.
Thank you, Michael!
So I need a linkMatcher for each "jump" in the depth of the graph, right?
I will test this solution.
Hi,
Glad I could help, please try it out and come back if you have troubles! Please try right now the JSON definition for the matchers.. as there is some nasty bug in the .ttl function, which we will investigate next week.
Michael
I doesn't understand very well your method. All leafes (red in the graphic) have the same predicate pointing to them. A predicate matcher is defined by a predicate; so, here, the red elements have only one predicate: rdf:type So, it will be only one template for each 'red' leaf
I suspect that what we need to define is a template for each type: one for Organization, one for Event...
Could you clarify?
First of all, the leafes should be normally literals. A predicate matcher which matches a URI is not really good, because a URI should not be shown to the user.
Second the leafes can definitely have multiple times the same predicate. That is why with combineMatchers and linkMatchers, they might group together the same predicates on different level of the graph and let the literals address it.
I'm quoting the sentence "So first we create predicateMatchers for all leafes (red in your graphic)" in a previous message Here, in the graphic, all the 'red' nodes are URI
Yeah ignore the remark with match the red stuff. As Michael wrote you can do it but it's not necessarily a good idea because lots of data will probably not have any classes assigned (ok we could infer them from the schema often but that's not part of the code).
So Michaels recommendation is to ignore the classes and do matchers only on predicate/literal levels. Once you did that, you create the linked matcher for the bigger structure.
Is it clearer like this? If no I think we should Skype :)
I think we should Skype
Dear All,
Assume you have the graph below.
If I decide to choose the "Event" entity as a subject, which matchers I should write in order to traverse the graph and get data related to the "Address" entity (for example the postal code)?
In general, what is the approach to get data in a deep graph? Could you write an example of matchers in the form of js objects and a simple template to read data?
Thanks!