recursive removal of objects from ore graphs

4 views
Skip to first unread message

Richard Jones

unread,
Jun 17, 2008, 12:34:50 PM6/17/08
to fore...@googlegroups.com
Hi Folks,

I'm looking into implementing some methods to allow me to remove
elements from ORE graphs, and also to detach elements from the
underlying model. This means following links as specified in the graph
and attempting to determine whether they should be removed/detached.

While it is wrong to think of this problem in terms of hierarchies, it
is not incorrect, I don't think, to regard the ORE specification itself
as imposing a kind of slightly tangled hierarchy. I'm using the below:

- Aggregation
- general triples
- Resource Map
- general triples
- Aggregated Resource
- general triples
- Proxy
- Proxy
- general triples

So imagine that I were to ask an Aggregation to remove all of its
contents. It would cascade through this hierarchy and basically remove
everything. But if I were to ask an Aggregated Resource to do the same
thing it would not attempt to remove any parts of the Aggregation or
Resource Map, it would only remove it's own internal graph of triples,
plus the Proxy and all of its associated triples. It's worth noting
that this is about removing triples, rather than references to
resources: if I remove a general triple which refers to a resource which
is also referenced elsewhere, this will not affect the second reference.

Does this make sense as an approach to people?

Cheers,

Richard

--
=======================================================================
Richard Jones | Hewlett-Packard Limited
Research Engineer, HP Labs | registered office:
Bristol, UK | Cain Road, Bracknell,
| Berks, RG12 1HN.
| Registered No: 690597 England
eml: richard...@hp.com -------------------------------------
blg: http://chronicles-of-richard.blogspot.com/
-----------------------------------------------------------------------
The contents of this message and any attachments to it are confidential
and may be legally privileged. If you have received this message in
error, you should delete it from your system immediately and advise the
sender. To any recipient of this message within HP, unless otherwise
stated you should consider this message and attachments as "HP
CONFIDENTIAL".
========================================================================

Dr R. Sanderson

unread,
Jun 17, 2008, 3:31:50 PM6/17/08
to fore...@googlegroups.com

It seems okay. The thing to be aware of, in the single-graph storage
model is whether or not there are any other references to an object or
not.

For example, say that you're trying to remove an aggregated resource.
You don't want to end up with an unconnected graph, so crawling outwards
you'd want to remove the type (say journal article), the creator and so
on. But you only want to remove the subsequent triples if there's no
other references.

eg:

uri-photo-1 creator uri-me
uri-me name "Rob Sanderson"

You'd need to check that uri-me is not the object of a relationship from
another resource.

Rob

Benjamin O'Steen

unread,
Jun 18, 2008, 5:29:21 AM6/18/08
to fore...@googlegroups.com
I'd also like to add the case of inter-resource triples:

e.g. consider

URI-AR1 a AggregatedResource
...blah...
dc:format "application/pdf"
dcterms:hasFormat URI-AR2

URI-AR2 a AggregatedResource
...blah...
dc:format "text/plain"

What do most people expect should happen if URI-AR1 is deleted? what is
expected if URI-AR2 is deleted instead?

IMO:
URI-AR1 can be lopped off without too much of an issue.

But if URI-AR2 is deleted, I'd actually expect the dcterms:hasFormat
triple that it is an *object* of to be removed as well.

My $0.02

Ben

Reply all
Reply to author
Forward
0 new messages