Good points, Ben. I've continued the discussion below.
---
A. Soroka
Software & Systems Engineering / Online Library Environment
the University of Virginia Library
On Thu, Feb 23, 2012 at 1:04 PM, Benjamin Armintor <armin...@gmail.com>wrote:
>
> This is one of the reasons I'd like to revisit the way these work in
> Fedora 4. I'd like to use them (really, I would!), but 1) they're limited
> in what they can do by the way Fedora interacts with them (simple string
> parms and http GET), and 2) they're just godawful slow.
>
> I think we all would. There are _many_ issues here, like the use of
complex (but mostly unique to the Fedora community) XML standards to define
disseminations, the limited power inside those definitions, and so on. It
may be time to step back and ask ourselves what kind of architectural
connection we want between the notions of "representation of an object" and
"dynamic behavior". The (very reasonable) complaints you're making, Ben
(and we all know that you are far from alone), are concerned with the
definition and implementation of dynamic behavior. The questions I would
like to offer in exchange are: what do we actually need from a design for
"dynamic behaviors" in order to fulfill the notion of "representation of an
object" in the sense in which Fedora's architecture deploys that notion? Do
the precise (but cumbersome and limited) formulations for defining dynamic
behaviors meet the needs? Does the technique of defining the contracts and
implementations for dynamic behaviors in the RDF object graph meet the
needs? Does the basic idea of supplying backend services for dynamic
behaviors via Web services meet the needs? Etc., etc.
> RE: IDs and URI
> I hope to see PID generation go away in favor of a pluggable ID minting
> service. PURLs, or handles, or ARK ids, and some code to reduce them as
> appropriate to be addressed as a resource in Fedora. It seems like old PIDs
> could be retrofitted with a proper server uri as a prefix for this.
>
This is actually something about which we spoke briefly at the very end of
the call, at the tail-end of discussion about the architectural nature of
Fedora's internal identifiers. I think I can reasonably summarize by saying
that we acknowledged an important architectural constraint: Fedora's
internal identifiers ought not to require to be dereferenced by
external-to-the-repo resources (for portability) and we were reminded that
it's _really_ nice when the internal identifiers are legal URIs, because it
becomes possible to use off-the-shelf RDF machinery to maintain the
internal semantic graph. Any implementation that fulfills these criteria
should be pluggable as a PID implementation. Those implementations that
break the portability constraint may be pluggable, but at a cost.
>
> RE: The Relative Priority of Graphs/RDF
>
> I think Adam is right here. In fact, this is such an important part of
> what we use Fedora for that searching these relationships is underserved.
> This again related to Dan's point about modeling- if the resource index is
> unusably slow, you'll be reluctant to bake an expectation of it into your
> models.
It's important to remember here that the Resource Index is (still!)
formally optional. If you're designing generically for Fedora, it is
_never_ appropriate to rely on the presence of the RI. Having said that as
required by law, I think we all know that there are plenty of practical
services in play now that would be unthinkable without the speed of the RI,
like ECM Repository Views or FESL RI XACML attribute retrieval, or many,
many local integrations.
At various times, the question has been raised as to whether to continue
the RI in its current "red-headed stepchild" mode as an optional part of
the core services, whether to push it out further towards the periphery
next to GSearch, or whether to embrace it fully and bring it into the core.
I'm very much of the latter opinion, but I'd love to hear other points of
view.
> On Thu, Feb 23, 2012 at 12:43 PM, Chris Wilper <cwil...@duraspace.org>
> wrote:
> > Hi all,
> >
> > The committers had a special topic meeting today covering Fedora's
> > relationship to web and semantic web architecture, inspired by some
> > discussion about Fedora support for Memento, but leading to much bigger
> > issues than that. I know there are folks who've been in the Fedora
> community
> > for a while who have thought about some of these bigger architectural
> > questions and would be interested, so I'm posting the notes below and
> > officially inviting anyone who's interested to participate here.
> >
> > What are some old assumptions that should be challenged, and how do we
> see
> > ourselves fitting in with the web, semantic web, and linked data world in
> > the future? This level of discussion is particularly important for us as
> we
> > look toward 4.0. Today's meeting was only intended as a kick-off
> discussion
> > -- hopefully we can continue it right here on mailing list in the coming
> > weeks.
> >
> > Thanks,
> > Chris
> >
> > [Topic areas]
> >
> > 1. What are the major similarities/differences between Fedora and Web
> > Architecture? The object/resource model. Identifiers, Formats, And
> > Protocols.
> > 2. Where does Fedora's architecture intersect with or diverge from Semweb
> > architecture?
> > 3. Should Memento support be added directly to Fedora's REST API, or
> > considered as a higher-level service (extension) on top of it?
> >
> > [Notes from Feb 23rd 2012 committer call]
> >
> > Chris: Start with how Fedora fits/doesn't fit into web architecture. Dan
> has
> > called Fedora a "Resource Store" vs a "Content Store". How does this
> concept
> > of resource differ from web arch's concept?
> >
> > Adam: CMA and dissemination architecture. A key distinction is that
> Fedora's
> > dynamic representations are highly specified, and the specifications
> > themselves are resources.
> >
> > Chris: So is Fedora just filling in details, or does it actually go in a
> > different direction from web arch?
> >
> > Adam: Fedora's object model is different. It's disseminations also look
> an
> > awful lot like member functions in OOP.
> >
> > Steve: It's also about fundamental responsibilities. Fedora's about
> curation
> > and dissemination. Fedora makes a distinction about identifying the
> > representation as a thing to be preserved!
> >
> > Dan: I believe Adam said "An archive needs to care how a representation
> is
> > created."
> >
> > Adam: Sounds good, I'll take credit.
> >
> > Dan: Hourglass design: push complexity to the edge and have simple stuff
> > (verbs, object models) in the "waist".
> >
> > Adam: Fedora's dynamic disseminations haven't got a lot of uptake.
> >
> > Chris: Complexity, approachability.
> >
> > Dan: Maturity.
> >
> > Adam: History…things have changed with Fedora. More emphasis now on the
> > graph of objects and relationships. Change ok.
> >
> > Dan: Also CMA. And people haven't experimented with alternate ideas for
> > content modeling as much as we'd hoped.
> >
> > Adam: ECM has. Others haven't in part because it's too hard.
> >
> > Chris: What about the REST api? Where do we fight the web architecture &
> > REST?
> >
> > Adam: Orchestration tools/APIs tend to be RPC-based, not resource-based.
> > Usually you talk about operations with SOAP. A REST API doesn't fit as
> well
> > there.
> >
> > Dan: Gigantic strength in seeing Fedora as middleware and not as a
> > repository. Having different interfaces is important.
> >
> > Chris: REST doesn't define Fedora, nor does SOAP. Still feel both are
> > important. Advantages of REST API over SOAP? Big one in my mind: ease of
> > integration with existing languages/tools. Success with SOAP tool interop
> > has historically been mixed, though it's getting better.
> >
> > Adam: (agree on SOAP tool interop)
> >
> > Frank: Also if you adhere to REST, you get some things for free. Caching
> on
> > top of Fedora via Apache. Can't do with SOAP API.
> >
> > Dan/Chris: Method-for-method equivalence of REST api and SOAP is not
> > necessary. But overall capabilities should be comparable.
> >
> > Dan: Fitting Fedora into a grand eventing architecture?
> >
> > Chris: Steve has suggested that more generic, resource-oriented events
> would
> > be good to publish from Fedora. Advantage is integration with more
> generic
> > (non-Fedora-specific) tools. Today we have Fedora-specific event-based
> > messages coming out. Need for both approaches?
> >
> > Steve/Others: Yes. Seems both have their place.
> >
> > Adam: On any given interface to Fedora, it seems like we want to
> consider a
> > Fedora-event-oriented exposure and a more generic resource-oriented
> > exposure.
> >
> > Chris: Now, where do things seem weird with semweb architecture and
> Fedora?
> >
> > Frank: Having ids for all Fedora entities makes sense. Referencing via
> URI.
> >
> > Chris: Use of the info: scheme seems to be one place we fight some
> accepted
> > semweb guidelines (linked data says http-only). The info-uri effort has
> been
> > discontinued, but thankfully, it wasn't designed with resolution in mind
> so
> > Fedora info: URIs will continue to be useful.
> >
> > Adam: A fundamental difference: In Fedora, the only place where I can
> make
> > an RDF assertion is inside the object that the assertion is persisted.
> >
> > Chris: I'd qualify that – you can make whatever RDF assertions you want
> > about Fedora object, but if you want them indexed by today's Fedora RI we
> > have certain restrictions on that.
> >
> > Adam: Steve presentation at OR: Pattern we've seen with Fedora is that
> > public ids have been exposed through some other system, not Fedora.
> Fedora
> > has internal ids.
> >
> > Steve: Was a "what if": Fedora as the curator of the public ids? Valid to
> > have an internal representation and a different public exposure of that
> > model, and a transformation between those things.
> >
> > Adam: Community seems to prefer not to use info: uri as public
> identifier.
> >
> > Dan: Nuanced conversation. Asking to potentially build some new core
> ideas.
> > Web arch. allows for private resolver systems. Was thinking of ideas that
> > came out of SOA community, notion of Fedora ecosystem providing a private
> > resolver system. A system for being an authority source for identifiers.
> >
> > Dan: If we provided technology or specifications for the IFAPs
> (Interfaces,
> > Formats, And Protocols) for federating Fedora, we can facilitate
> communities
> > who are actually putting federations together.
> >
> > Steve: Fedora has a role as registry repository.
> >
> > Dan: Can act as resolver system, but can be made better.
> >
> > Adam/Chris: Should Fedora's REST api endpoints be considered Durable or
> > Linked Data Friendly?
> >
> > Dan/Chris/Adam: We should be very clear about that.
> >
> > Dan: Also Fedora needs to re-address notion of versioning and migration.
> > Fundamental pattern of a bolt-on in Fedora to handle migration. Might
> not be
> > all of memento.
> >
> > Chris: If REST API is not intended to provide durable ids for things,
> > memento doesn't belong there.
> >
> > Dan: We often leave out the Federation of repos.
> >
> > Steve: Believe it's very important that Fedora have an internal id.
> >
> > Chris: Using URIs for internal ids works well today because we have
> > standards (rdf) to relate them.
> >
> > Frank: What about UUIDs? Easy to generate.
> >
> > Chris: Also URI-compatible. It's convenient in any case for Fedora to
> > continue allowing people to mint ids outside the repository.
> >
> > Adam: Anti-pattern we see a lot of: putting semantics in ids. But human
> > nature.
> >
> > Steve: From a long term preservation perspective, you'd want to isolate
> > yourself from current trends, standards.
> >
> > Chris: Riding waves is good, but we're not defined by them.
> >
> > --
> >
> > Notes
> > from
> https://wiki.duraspace.org/display/FCREPO/2012-02-23+-+Special+Topic+-+Fedora%2C+Web%2C+and+SemWeb+Architecture
> >
> >
> >
> ------------------------------------------------------------------------------
> > Virtualization & Cloud Management Using Capacity Planning
> > Cloud computing makes use of virtualization - but cloud computing
> > also focuses on allowing computing to be delivered as a service.
> > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > _______________________________________________
> > Fedora-commons-developers mailing list
> > Fedora-commons-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
> >
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Fedora-commons-developers mailing list
> Fedora-commons-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Fedora-commons-developers mailing list
Fedora-commons-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
