uduvudu / uduvudu

Uduvudu
MIT License
17 stars 6 forks source link

How to get data in a deep RDF graph using matchers #21

Closed giuseppefutia closed 9 years ago

giuseppefutia commented 9 years ago

Dear All,

Assume you have the graph below.

data-model.

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!

l00mi commented 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.

giuseppefutia commented 9 years ago

Thank you, Michael!

So I need a linkMatcher for each "jump" in the depth of the graph, right?

I will test this solution.

l00mi commented 9 years ago

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

moissinac commented 9 years ago

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?

l00mi commented 9 years ago

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.

moissinac commented 9 years ago

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

ktk commented 9 years ago

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 :)

moissinac commented 9 years ago

I think we should Skype