compared with
Current by Vladimir Alexiev
on Jan 28, 2013 10:47.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (2)

View Page History
- breadth or depth-first walking? Does it matter?

{info:title=Lesson Learned for RS4}
Overall, I now think the way we try to figure out the extent of an object's graph is wrong.
- It's too brittle: data variations easily break it, adding data breaks it...
See one of the most insidiuous leaks: {jira:RS-1375}
- It's expensive both in terms of queries and processing
- It's a complicated algorithm.

The most logical approach is to use the named graph for this (one graph = one object).
{info}

h2. CRM redundancy
CRM has various redundancies
#- But we still need to fetch its rdf:label(s)!

h1. Named Graphs instead of Graph Walk

{info:title=Lesson Learned for RS4}
Overall, I now think the Graph Walk that we do to figure out the extent of an object's graph is wrong.
- It's too brittle: data variations easily break it, adding data breaks it...
See one of the most insidiuous leaks: {jira:RS-1375}
- It's expensive both in terms of queries and processing
- It's a complicated algorithm.

The most logical approach is to use the named graph for this (one graph = one object).
{info}

- Dominic said the same at a call 20120125 re the performance of the Graph Walk algorithm
- Josh emits the statements for <object> in named graph <object>/graph.
It's better to use just <object> for the graph URI, since one is not supposed to manipulate URIs (they are supposed to be opaque)
- But things are not so simple, because only the *explicit* statements are in the per-object graph
The *implicit* (inferred) statements are in the empty (default) graph. They can also be fetched from the special ("magic") onto:implicit graph, which includes no explicit statements.
-- Dominic asked how important inference is for the CompleteMO (i.e. RForm detailed object view). It's used for:
--# P140i (see [#Remove Shortcut Property of Association] above), i.e. to get to all association codes.
--# Fetching some subprops (eg BM ext props) as the base CRM prop, eg:
bmo:PX_curatorial_comment as P3_has_note, bmo:PX_likelihood as P2_has_type, P131_is_identified_by as P1_is_identified_by
-- Vlado talked to the OWLIM team re the feasibility of an enhancement that would put inferred statements in a specific graph (predefined, or dynamically computed from the premises). Damyan explained that this is infeasible, because it can lead to the same ontological statement being asserted in each object's named graph, and for a variety of other technical issues.

Vlado: here's an idea for a 2-step algorithm:
# Get all statements <s,p,o,g> in the object's graph g
# Extract all distinct Nodes from these statements
Note: we also need literals, not just URIs!
# Get all inferred statements <?s, ?p, ?o, onto:implicit> where
?s,?o are in the set extracted above
?p is a business property

TODO: precise the above:
- should *both* ?s,?o be in Nodes, or it's enough for *one* of them to be?
- assess how long are the lists of Nodes (max 300 per object?) and Business Properties (about 140), and what impact that has on the query

h1. EntityAPI
Input: URI of a Museum Object (MO)