Thinking on this some more from an identifiers perspective:
We currently have the following kinds of identifiers[*] in Fedora (feedback
welcomed for those I have missed or got wrong):
- SOAP API, eg
-- object: pid
-- datastream: pid and dsID in conjunction
-- dissemination: pid, sDefPid and methodName in conjunction
- the "LITE" APIs (API-A-LITE and API-M-LITE), eg
-- repository: [server]/fedora/describe
-- object: [server]/fedora/get/{pid} (resolving to the object profile)
-- datastream: [server]/fedora/get/{pid}/{dsID}
-- dissemination: [server]/fedora/get/{pid}/{sDefPid}/{methodName}
- the existing REST API, eg
-- object: [server]/fedora/objects/{pid} (resolving to object profile)
-- datastream: [server]/fedora/objects/{pid}/datastreams/{dsID}/content
- the info:fedora URI scheme (used by the resource index), eg
-- object: info:fedora/{pid}
-- datastream: info:fedora/{pid}/{dsID}
-- dissemination: info:fedora/{pid}/{sDefPid}/{methodName}
And we potentially have identifiers for:
- the proposed new REST API
- named graphs "about" Fedora resources
([*] These are not necessarily all formal identifiers, in some cases they
are simply URLs that resolve to something useful - however these can
function as identifiers in that they represent ways in which Fedora
resources may be referred to, people may cite them, bookmark them, link to
them, etc.)
Plus we also have URLs for services that should be part of this perspective,
eg fedora/search, fedora/riseach, plus the API methods that are not bound to
objects (describeRepository, getNextPid).
I think it would be useful to have a single table, on the wiki somewhere,
bringing these all together. It could help in maintaining a consistent
identifier syntax (where possible) across different identifier schemes
(simplifying coding), and also clarify what an identifier identifies, and
what it resolves to.
And to mix it all up a bit more...
In terms of identifiers that identify resources and identifiers that resolve
to representations, Fedora seems to follow ([1], [2]) a model of having
digital object identifiers for a resources, and datastream/dissemination
identifiers for representations; but at the same time not "enforcing" this,
allowing for numerous flexible modelling approaches in practice.
Cool URIs and Linked Data perspectives distinguish between identifiers that
refer to a "thing" and identifiers that identify (eg) a web page describing
the "thing", with both resolving to the same web page. Does a Fedora
digital object identifier refer to what the URL resolves to, or is it a
identifier for what the digital object represents? Probably the former (the
object in the repository) - should there also be identifiers for the latter?
Or is this nothing to do with Fedora per se, and down to implementors to
determine for themselves?
There's also OAI-ORE: for instance having different URIs for identifying a
resource (aggregation) and its graph representation (as per Cool URIs);
utilisation of HTTP 303 and content negotiation for mediating between
resource identifiers and graph identifiers; and also having different URIs
for different expressions (eg RDF/XML and Atom) rather than using the same
URI and using HTTP content negotiation.
[1] The Fedora Digital Object Model - Access Perspective (Fedora wiki):
http://www.fedora-commons.org/confluence/display/FCR30/Fedora+Digital+Object
+Model#FedoraDigitalObjectModel-DigitalObjectModelAccessPerspective
[2] Fedora: An Architecture for Complex Objects and their Relationships
(Carl Lagoze, Sandy Payette, Edwin Shin, Chris Wilper):
http://arxiv.org/abs/cs/0501012v6
Regards
Steve
> -----Original Message-----
> From: Steve Bayliss [mailto:[email protected]]
> Sent: 09 November 2009 12:31
> To: 'Asger Askov Blekinge'
> Cc: [email protected]
> Subject: Re: [Fedora-commons-developers] The REST API,The
> Resource Index and the Semantic Web
>
>
> Hi Asger
>
> Thanks for your comments on this
>
>
> > As far as I can see, you actually assume that the triple
> store is only a
> > cache, but you do require that it exist. "Triple store is
> only a cache"
> > means somewhat the same as "every triple in the triplestore
> should be
> > expressed in one of the objects"
>
> Yes, I think you are right here that the triple store is a
> cache (no direct
> writes allowed). In terms of requiring it to exist, I can
> see a scenario
> where RI is not enabled, the REST API functions as it should,
> and a new
> "unified relationships" API method could still work providing
> the correct
> "resolution" mechanism was in place to relate a triple
> pattern back to the
> "owning" object.
>
> >>
> >> Essentially some kind of hierarchy of graphs and views, for example
> (please
> >> ignore the actual model/graph identifiers used below, I've
> not thought
> those
> >> through... this is just for conceptual illustration!).
> (and note that
> these
> >> are not Fedora resource identifiers - they are identifiers
> for graphs and
> >> sub-graphs describing Fedora resources, with triples
> containing URIs that
> >> resolve to Fedora resources.)
> >>
> >> <snip/>
> >>
>
> > And you have thus beautifully solved an old Fedora problem!
>
> I think this could work - but the impact on performance would
> need some
> investigation.
>
> >>
> >> Mapping between Fedora objects and the resource index
> >> =====================================================
> >>
> >> <snip/>
> >>
> >> For instance the base content model that every object
> belongs to could
> >> specify:
> >> - an XSLT for generating the "system" triples for Fedora object and
> >> datastream properties, relationships between objects,
> datastreams and
> >> disseminators; and which graph the triples should be added to
> >> - an XSLT for generating triples from RELS-EXT; and which graph the
> triples
> >> should be added to
> >> - an XSLT for generating triples from RELS-INT; and which graph the
> triples
> >> should be added to
> >>
> >> <snip/>
> >>
> > I was actually thinking that this could be expressed as
> disseminators.
> > Then the content model would only have to express which
> disseminator to
> > call.
>
> That could be one way I guess, specifying a disseminator
> which transforms to
> RDF, and then index the results
>
> >> This needs thinking about more, for instance if an
> arbitrary triple is to
> be
> >> added, what object should it be stored in (that is a
> triple that does not
> >> make an assertion about a Fedora object or datastream for example)?
> Should
> >> it be possible to add a triple(s) that assert a new
> datastream or Fedora
> >> object? (ie having a completely RDF-centric API).
> > I feel a useful distinction could be statements to create
> new graphs,
> > and statements to add triples to a graph. Graphs should
> only be created
> > through the "traditional" API, as they create new objects and
> > datastreams.
>
> I think I agree here... though I can see a situation where
> adding/asserting
> a new triple that states an object exists results in its creation (and
> creation of the other triples it implies)...
>
> Steve
>
>
> --------------------------------------------------------------
> ----------------
> 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
>
------------------------------------------------------------------------------
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
