Hi Steve,
On Fri, Nov 6, 2009 at 4:36 PM, Steve Bayliss
<[email protected]> wrote:
> Thinking over the current debates over the REST API, particularly
> manipulating relationships, and how the resource index fits in with this, I
> wonder if there is some unified approach that could be used to relate all of
> these together in a semantic web-friendly, REST-friendly, Web 2.0-friendly
> model.
I hope so. It looks like you're taking a good hack at it here.
> [..]
> So completely ignoring the
> "triplestore-is-only-a-cache-and-might-not-even-exist" issue...
As you pointed out later in the discussion, it may be possible to do a
lot of this stuff (minus whole-respository querying) with the RI
turned off.
> The Resource Index and graphs (models)
> ======================================
> [...]
> <#ri> - a view containing:
> <#some:pid> - object graph for some:pid, a view containing:
> <#some:pid/properties> - graph containing object properties
> <#some:pid/datastreams> - a view containing:
> <#some:pid/datastreams/rels-ext> - graph containing triples from
> <#some:pid/datastreams/{rdf datastream}> - graph containing triples
> from some other rdf datastream
I really like this thinking, especially combined with this:
> Resolvable RI URIs - being more Semantic Web- and Web 2.0-friendly
> ==================================================================
> [...]
> It could also be useful to also expose resolvable URIs in the resource
> index, as an alternative view. For instance, something akin to a
> URL-rewriting mechanism could be used to transform <info:fedora/some:pid>
> into http://server:port/fedora/objects/some:pid (using the proposed
> alternative REST API syntax).
> [...]
> It should also be possible to disseminate sub-graphs with resolvable URIs as
> (for example) OAI-ORE resource maps.
This alternative view, divorced from Fedora-specific URIs, would make
future versions very Linked Data-friendly.
+2
> Mapping between Fedora objects and the resource index
> =====================================================
> Currently the specification of what triples get created for Fedora objects,
> datastreams and properties is embodied in imperative Java code.
> [...]
This could get hairy, but I like the idea of going declarative where
possible, because it means easier extensibility. Maybe using the
disseminator pattern could make this more "pluggable" as Asger pointed
out, but I'm not seeing an obvious way yet.
> Persistence is fundamental - all relationships should be stored in the
> filesystem - adding triples to Mulgara without persisting them in the Fedora
> object model should not be allowed.
+1 I think getting the bits into regular files at *some point* is key
to Fedora's suitability for preservation.
Very good discussion...looking forward to more.
- Chris
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers