Fedora (?) Community Data Model

[Cowles, Esme]

There has been some discussion on the FCDM wiki page[1] about the model. There are two things in particular that I think are worth calling out to the broader community:

- There was an objection to including the FCDM ontology in the fcrepo4 ontology repo and namespace, and a suggestion that somewhere less closely tied to fcrepo4 would be more appropriate. I know there are some people who are interested in the model using other platforms, so that could be a good move. Does anybody have an alternative to suggest? http://opaquenamespace.org/model# ?

- The other issue is related to the hasMember and aggregates properties. In the discussions after code4lib, we decided to make fcdm:hasMember a sub-property of dcterms:hasPart instead of ore:aggregates, to avoid problems trying to find aggregated resources separate from members. Rob rightly noted that the ore:Proxy membership requires the predicate to be a sub-property of ore:aggregates, so I've changed that back. I believe people can still find aggregated and member resources separately, but I want to ask if anybody has any concerns about this.

-Esme


1. https://wiki.duraspace.org/display/FF/Fedora+Community+Data+Model

[aj...@virginia.edu]

I may very well be misunderstanding this issue, but why cannot fcdm:hasMember be a subproperty of both?

---
A. Soroka
The University of Virginia Library

[Esmé Cowles]

Adam-

It is indirectly since ore:aggregates is a sub-property of dcterms:hasPart. I think the issue that was expressed was that both relationships derived from ore:aggregates and so queries based on ore:aggregates would find both, therefore making it hard to find aggregated resources but not members.

But thinking about that now, I think that would only be an issue in an environment with reasoning enabled, and that in fcrepo4 and any non-reasoning triplestore, that wouldn't happen. So I'm mostly asking if I'm remembering the issue clearly, or if there is some other issue with the fcdm:hasMember being a sub-property of ore:aggregates.

-Esme

> --
> You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
> To post to this group, send email to fedor...@googlegroups.com.
> Visit this group at http://groups.google.com/group/fedora-tech.
> For more options, visit https://groups.google.com/d/optout.

[Tom Johnson]

> therefore making it hard to find aggregated resources but not members.

What is the use case for this?  Perhaps we mean something more specific than `ore:aggregates` by "aggregated resources but not members"?

It seems like a bad reason to rip up the property hierarchy, anyway. As you note, a simple sparql query against the `ore:aggregates` predicate will find the relevant resources.  Even in an reasoning environment, it's typically the default to ignore inferred triples.

- Tom

--

-Tom Johnson

[Stefano Cossu]

Esmé,

I find it more suitable to look at the relationship in logical terms: if
fcdm:hasMember is logically a sub-property of ore:aggregates, why
shouldn't it be defined as such? You can still formulate a query that
searches for aggregates and excludes members.

I am saying this because we plan on using a reasoner in our triplestore
index, but I don't find this to be an issue.

Stefano Cossu
Director of Application Services, Collections

The Art Institute of Chicago
116 S. Michigan Ave.
Chicago, IL 60603
312-499-4026

[Andrew Woods]

Thanks for starting the thread, Esmé.

I do not want to lose track of your first question:

>> - There was an objection to including the FCDM ontology in the fcrepo4 ontology repo and namespace, and a suggestion that somewhere less closely tied to fcrepo4 would be more appropriate.  I know there are some people who are interested in the model using other platforms, so that could be a good move.  Does anybody have an alternative to suggest?  http://opaquenamespace.org/model# ?

Initially the FCDM work was falling under the Hydra namespace. Then it became clear that the FCDM also resonated with Islandora and custom Fedora installations. At that point, the common denominator was Fedora, and hence the proposal to host the FCDM ontology under a Fedora namespace.

If there is a more appropriate hosting namespace to use, let's get it on the table. Obviously the sooner that is agreed upon, the less potential downstream impact. In the absence of an alternative and from the candidates on the table, Fedora may be the best option.

Suggestions requested.

Andrew

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.

To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.

[Robert Sanderson]

Requirements would be: 

  * Space for publishing

  * Space for communication

  * Clear licensing/IPR requirements

  * Ability to participate without significant cost

  * Organization is responsive to requests

  * Provide a stable home

To me, this rules out OAI and W3C, though would be prepared to act as a liaison to either. It also rules out projects such as LD4L, as they're temporary constructs.

Given these, I think that Fedora is as good a home as any, so long as we're very clear in the communication of the model that 

 * It does not require Fedora

 * Fedora does not require it

 

Rob

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.

To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.

--

Rob Sanderson

Information Standards Advocate

Digital Library Systems and Services

Stanford, CA 94305

[aj...@virginia.edu]

I raised the objection, so let me fill it out a bit, starting from this point:

"At that point, the common denominator was Fedora…"

I can't agree. At this point, the common denominator is: those Hydra and Islandora institutions that have participated in this discussion. I'm personally not very clear how the discussion has proceeded or where it is expected to go, and I'm not sure how well-publicized we can consider it to have been to the broader Fedora community, but in any event, that broader community includes plenty of institutions that are using neither framework and I find it hard to believe that the communities around those frameworks have been perfectly represented by a meeting at code4lib and the other pieces of this discussion. Certainly, I may be very wrong.

Part of the power (and longevity) of Fedora has come out of the ability it provides its community to experiment with sophisticated content modeling. This effort, while excellent in its own right, is specifically aimed at those institutions that choose to model their resources around library-ish concepts like "collections". That is a large portion of the Fedora community, but not all of it by a long ways.

As for an appropriate home for this effort: that's up to the Hydra and Islandora communities. I think them more than capable of shouldering the burden.

---
A. Soroka
The University of Virginia Library

> To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.

> To post to this group, send email to fedor...@googlegroups.com.
> Visit this group at http://groups.google.com/group/fedora-tech.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "Fedora Tech" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.

> To post to this group, send email to fedor...@googlegroups.com.
> Visit this group at http://groups.google.com/group/fedora-tech.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Fedora Tech" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.

[aj...@virginia.edu]

On Feb 27, 2015, at 4:28 PM, Robert Sanderson <azar...@gmail.com> wrote:

> Requirements would be:
> * Space for publishing
> * Space for communication
> * Clear licensing/IPR requirements
> * Ability to participate without significant cost
> * Organization is responsive to requests
> * Provide a stable home

You don't consider the Hydra and Islandora communities to fulfill these characteristics?

[Andrew Woods]

Hello Adam,

My suspicion is that if this ontology/work were to be termed "Islandora Community Data Model", it would alienate non-Islandora installations. Likewise, if it were to be termed "Hydra Community Data Model". There is both the question of what is the effort named? as well as under what namespace is it hosted? 

The most viable candidate yet on the table is:
- Fedora Community Data Model
- http://fedora.info/definitions/v4/models#

I do not think that anyone is suggesting that the principles offered in the FCDM are the *only* way of modeling data in Fedora, but rather a strong reference model around which the greater repository community can develop a shared understanding.

Andrew

[aj...@virginia.edu]

I think we're talking "at two different angles", Andrew.

I agree that those are important questions for this effort. I don't agree that they are the responsibility of the Fedora community, because I don't agree that this effort is the responsibility of the Fedora community, and that's the root of my objection.

I appreciate your point about the nature of a reference model. I think you'll agree that it would be disingenuous to claim that the existence of a "reference model" will not stifle the flow of resources to other modeling efforts. If that were not the case, then we would have many different widely-available Fedora Commons implementations from which to choose today, instead of one "reference implementation".

---
A. Soroka
The University of Virginia Library

[Scott Prater]

FWIW, we've started reviewing the FCDM here at the University of
Wisconsin, with a view of migrating from our custom Fedora 3.0 content
model implementation and applications (no Hydra, no Islandora) to Fedora
4 at some point in the future. What we've seen described on the FCDM
page looks very promising, fairly agnostic in terms of the types of
content being modelled (especially if you interpret the idea of
"Collections" as a broader, abstract category), and doesn't smell of a
particular architecture, software stack, or even type of user.

As I understand it, the FCDM project may have arisen out of the needs
and discussions of the Hydra and Islandora communities, but it is by no
means applicable to just that subset of Fedora users; I think there's
something there for everyone. Nor is it an all-or-nothing,
take-it-or-leave it proposal -- institutions may see fit to adopt
certain aspects of the model, but not others (WebACLs, for example, are
unlikely to play any part in our objects). Nor is it fixed in time --
from what I've gathered, part of the purpose of the FCDM project is to
move it beyond the Hydra and Islandora communities, evolve into
something more general-purpose, make it something with that will be
applicable to a variety of institutions and types of content (although,
if our implementation happens to speak the same language as
Hydra/Islandora applications, so much the better for interoperability).

With all that in mind, Fedora seems to be the natural home for it, under
the auspices of the Duraspace infrastructure. I take your point, though
-- maintenance and discussion of a descriptive, best-practice but
by-no-means-mandatory data model should be kept at arm's length from the
work of the Fedora repository software; no carts should be placed in
front of any horses.

It may be useful to hear from other Fedora users that are not museums or
libraries, to see what their reaction is to the FCDM.

-- Scott

--
Scott Prater
Shared Development Group
General Library System
University of Wisconsin - Madison

[Esmé Cowles]

Adam-

I really don't understand how this is different in any way from the other optional components hosted in the Fedora github organization and documented in the Fedora wiki. The Fedora project hosts two different authentication implementations, and two separate message processing platforms, for example, that many people in the community don't use. But I have no objection to them using the Fedora github/wiki.

The data model seems very analagous to me: an effort by a subset of the Fedora community, that is related to Fedora but not tightly bound. It seems entirely appropriate to use the Fedora project resources for this.

-Esme

[Andrew Woods]

Note: the Hydra and Islandora lists keep getting dropped off of this thread.

Thank you for your input, Scott. The University of Wisconsin is a concrete demonstration of how the FCDM can bridge the diversity of Fedora installations. The more we as a community can collaborate on common concerns, such as data modeling, the stronger and more validated the eventual solutions become.

The FCDM is a great opportunity to have an inclusive discussion of effective ways to employ Fedora and linked data principles. It would be a shame to squander that opportunity.

As for other repository community members that do not use Islandora nor Hydra, or that are not museum nor library nor cultural heritage institutions for that matter, these community members are warmly invited to contribute to the evolution of the FCDM as well. That is the point! 

Andrew

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.

To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.

To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.

To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.

--

Scott Prater
Shared Development Group
General Library System
University of Wisconsin - Madison

--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.

[Tom Johnson]

Thanks Scott, for sharing your interest and perspective.

It's heartening to hear, since the general applicability you ascribe to the model seems to be to have been it's foremost design goal.

As your message suggests, there's little harm in continuing this collaboration under the heading of "Fedora" as long as we communicate well about the applicability of the model.

I think our communication struggle is more likely to center on the messaging surrounding "Collections" and "Works"/"Objects" than Fedora. This is especially so since, in light of current issues surrounding LDP and the model's interpretation of it, significant portions of the model may in fact require Fedora.

- Tom

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.

To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.

To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.

To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.

--

Scott Prater
Shared Development Group
General Library System
University of Wisconsin - Madison

--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.

To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.

--

-Tom Johnson

[Robert Sanderson]

s/interpretation/use/

s/require Fedora./require a good implementation of LDP./

<w3c hat>

Please note that LDP was promoted to full technical recommendation this week, and is thus now stable.  Hopefully other LDP implementations will be improved to the same quality as Fedora's extremely thorough and compliant implementation.  Bravo to the Fedora community for being progressive and persistent in adopting international standards, and especially Chris Beer and Andrew Woods.

</w3c hat>

 

Rob

To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.

To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.

--

[Tom Johnson]

> s/interpretation/use/

This I'll agree with, since I don't see that it makes a difference.

> s/require Fedora./require a good implementation of LDP./

Now this is *dis*heartening to hear.  I think it's clear that LDP is not very opinionated about what happens when creating a resource see, especially 5.2.3.12:

Upon successful creation of an LDP-NR (HTTP status code of 201-Created and URI indicated by Location response header), LDP servers may create an associated LDP-RS to contain data about the newly created LDP-NR. If a LDP server creates this associated LDP-RS, it must indicate its location in the response by adding a HTTP Link header with a context URI identifying the newly created LDP-NR (instead of the effective request URI), a link relation value of describedby, and a target URI identifying the associated LDP-RS resource [RFC5988].

Implementations ("good", conforming implementations) are all over the map about the locations of those resources and their containment relationships to the created LDP-NR.  If the model's *use* of LDP relies on one implementation, that's a problem for non-Fedora LDP users.

I'm hopeful that LDP will provide better guidance about interoperability among the various interpretations of the above clause in the future. In the meanwhile, we (with our FCDM hats on) shouldn't be pretending that among differing implementations of deliberately vague clauses, one is "good" and others are not.

- Tom

-Tom Johnson

[Robert Sanderson]

On Fri, Feb 27, 2015 at 4:39 PM, Tom Johnson <johns...@gmail.com> wrote:

> s/require Fedora./require a good implementation of LDP./

Now this is *dis*heartening to hear.  I think it's clear that LDP is not very opinionated about what happens when creating a resource see, especially 5.2.3.12:

Upon successful creation of an LDP-NR (HTTP status code of 201-Created and URI indicated by Location response header), LDP servers may create an associated LDP-RS to contain data about the newly created LDP-NR. If a LDP server creates this associated LDP-RS, it must indicate its location in the response by adding a HTTP Link header with a context URI identifying the newly created LDP-NR (instead of the effective request URI), a link relation value of describedby, and a target URI identifying the associated LDP-RS resource [RFC5988].

Implementations ("good", conforming implementations) are all over the map about the locations of those resources and their containment relationships to the created LDP-NR.  If the model's *use* of LDP relies on one implementation, that's a problem for non-Fedora LDP users.

I would agree with that ... but don't see where the current -model- falls foul of it? 

The Fedora implementation of 5.2.3.12 does exactly as above.  It happens to always put the describing resource in the same relative location, but it does indicate that location in the required way.  If an implementation of LDP does not implement that, then a client can always manually create an rdf-source with the appropriate describes relationship and metadata about the non-rdf source.

 

So I fail to see what's preventing the use of another LDP system here. Also, an implementation that implements optional features *is* better than one that doesn't. Similarly lack of support in an implementation for Direct and Indirect containers would hamper implementation to some degree, but would simply require a client to make all of the assertions by hand, it would not prevent that system from being used at all.

 

I'm hopeful that LDP will provide better guidance about interoperability among the various interpretations of the above clause in the future. In the meanwhile, we (with our FCDM hats on) shouldn't be pretending that among differing implementations of deliberately vague clauses, one is "good" and others are not.

There are intentionally vague aspects to LDP, but 5.2.3.12 is not one of them, nor the definition of containers.  Any vagueness there is entirely unintentional.  Blank node handling, on the other hand ... :(

R

[Tom Johnson]

> but don't see where the current -model- falls foul of it?

The *model* does not. But as discussed in the (unfortunately off-list) technical metadata email thread the week before last, proposed mappings between the model and LDP do.  As near as I can tell, there is no support for non-RDF metadata associated with Files in Fedora without that mapping. Due to incompatibilities arising from 5.2.3.12 (again, as near as I can tell) we haven't been able to propose a mapping that would work across LDP servers. That seems like a problem.

> Also, an implementation that implements optional features *is* better than one that doesn't. 

I agree, and I eagerly await Direct and Indirect Container support in Marmotta. Thankfully, as you say, I don't believe the lack of that support will prevent anyone from implementing FCDM with basic containment in a way that produces isomorphic graphs (minus LDP specific classes). Differences related to 5.2.3.12 *will*, I think. And there it seems the fault lies on all sides, since the spec is not particular, and the implementations are incompatible.

- Tom

[Robert Sanderson]

Sorry, I need a little bit more help to understand the issue!

5.2.3.12 is pretty explicit that an LDP server MAY create an rdf source to hold the metadata about a non-rdf source, and if it does, then it MUST give the URI of that rdf source in the describedby link header.

Thus a conservative client that wants to perform operations on the metadata about a non rdf source will do a HEAD request on the non rdf source, find the describedBy link, and then work with the target URI from there (either to retrieve, update, and so on).  A fedora specific client might (naughtily) assume that the metadata will be at uri-ldpnr/fcr:metadata which would not be correct for other implementations ... and hence a good implementation of the FCDM would not do that.

To get non RDF metadata associated with the file, you would simply need to update that resource with the relationship of how some non rdf source is related to the described non-rdf source.  LDP does not specify how to associate non rdf source directly with non rdf source, which seems very reasonable for a *Linked Data* Platform :)  To do so would likely be very use case specific.

And thus we need the hasRelatedFile workaround that the LDP document describes at a URI level, and the model includes (modulo our current discussion) at the abstract level.  This is why we need the model in the first place, so that we as a (self-selecting) community can agree upon the patterns we want to use within the rope given to us by the standards. 

Rob

[Aaron Coburn]

Hello All,

As I understand it, Adam raised two concerns about where the FCDM is hosted: (1) related to hosting the ontology in the http://fedora.info namespace and (2) related to hosting the code for the ontology in the https://github.com/fcrepo4 organization.

Related specifically to the second point, there was a conversation last week on IRC with the suggestion that there be a new github.com organization (e.g. fcrepo4-extras) for exactly such code. The indexing ontology would be another good fit for this -- optional projects that are related to the fcrepo effort but very loosely bound to the repository codebase.

At present, this is only a suggestion (including the name), but it would allow us to sidestep the issue of putting these projects in fcrepo4-labs on a more permanent basis (i.e. being in fcrepo4-labs implies that the project is experimental and *may* at some point graduate into the full fcrepo4 organization).

If this seems, in principle, like a good idea to the community, we would need to clarify exactly what belongs in an eventual fcrepo4-extras github repository and what belongs in the fcrepo4 github repository. Presumably, the same process for graduating from fcrepo4-labs would apply to both.

Regards,
Aaron

[aj...@virginia.edu]

I think the crucial issue for distinguishing them is that of responsibility.

Material in fcrepo4 itself is material for which the Fedora community in entirety accepts the entire responsibility and those resources associated with the whole community are brought to bear on it.

Material in fcrepo4-labs is material for which some portion of the community accepts responsibility now, but for which there is a firm expectation that on some definite schedule, the whole community will accept responsibility, when it would move to fcrepo4.

Material in fcrepo4-extras would be material for which some agent accepts responsibility (and that identity would be clearly recorded in any material deposited in fcrepo4-extras). That agent may or may not be part of the larger Fedora community (e.g. Hydra and Islandora certainly are). There would be no expectation that such material will ever be in the remit of the entire community, there would be no expectation that any resources of the entire community would be expended on maintaining it (e.g. committer time), or that any particular imprimatur is given to it, other than the recognition that it is related to Fedora and that some people who use Fedora have found it useful. If it were ever to become part of the main mass of material in fcrepo4, it would have to pass through fcrepo4-labs first.

---
A. Soroka
The University of Virginia Library

[Scott Prater]

Although it's implied by the word "extras", I would also explicitly call
out that nothing in fcrepo4 should ever depend on, or even refer to,
anything in fcrepo-extras.

-- Scott

[Benjamin Armintor]

I think I understand what Adam is arguing and agree with it, but that only underscores my confusion about the extras organization and what we hope to accomplish with it. It seems like there are two modeling efforts going on in part of the community- the folks in that part of the community should decide if they want a shared space for it. The fcrepo organization doesn't need to get involved, does it?

[aj...@virginia.edu]

I understand your confusion, Ben. As I've made perhaps over-abundantly clear, I am not in favor of bringing the FCDM effort into any formal relationship with Fedora (I don't even like the fact that the word "Fedora" is used for it). I do think that the -extras organization would be useful for such things as the ontologies associated with Fedora-specific products such as the indexing frameworks or some of the code that actually uses those ontologies. To my mind, as I said before, the -labs space should be dedicated to only those products that are actually expected to become part of the core (and the core space would contain only the specifications, ontologies, test kits, and reference implementation of Fedora). That is not how things are arranged now, but the current arrangement was not constructed in as rich an environment as we now share.

---
A. Soroka
The University of Virginia Library

[Esmé Cowles]

Ben-

The reason why we thought to move the model under the fcrepo organization was that it seemed more inclusive of non-Hydra folks who were interested in joining the effort. So it seemed like the logical step to broaden the effort. Of course, not all fcrepo users will be interested in the model, and some people using the model won't be using fcrepo. So it's a somewhat awkward fit, and adding a scope section to the data model docs to clarify that would probably help.

Setting up a new github org for peripheral Fedora community projects seems reasonable to me, particularly if there are other projects that could be moved to the new org to make their relationship to fcrepo4 more clear.

-Esme

[Benjamin Armintor]

Esmé-

I agree with the intention and also that it's a little awkward!

Maybe something under https://github.com/duraspace, or a new org like duraspace-models, for the ontology work.

I'm reluctant to endorse the peripheral projects space because it seems mostly like an administrative headache to maintain teams and what-not for a project just to house it in a shared space that is defined as being unsupported. This seems like a job for a wiki page.

- Ben

[aj...@virginia.edu]

This sounds like a better idea than putting this ontology work in fcrepo4-extras. It would follow that an appropriate non-Fedora specific namespace could also be associated to it in a similar way.

I do think that there is some value in making the shared space available for such constructions as the indexing frameworks, because so doing will clarify the role of fcrepo4-labs as a place reserved for projects with a concrete plan to graduate into the core. Admittedly, that's rather a negative sort of value.

---
A. Soroka
The University of Virginia Library

[Robert Sanderson]

I'm not interested in an audit service. Please don't implement an audit service that I don't want in the main repo. It should live in an add-on space. Then I can choose to use it or not.

I'm sure this sort of statement would be laughed off the list.  A model and/or code that is 100% ignorable if you don't want to use it seems even less contentious than an audit service. There's a significant number of institutions that want to collaborate and use a shared model, but not everyone.  I'm sure there's institutions that don't want an audit service. Or a SPARQL endpoint. Or LDP. Or ...

Why is documentation and helper implementation code for a model any different?

Rob

[aj...@virginia.edu]

I'm a committer and a long-standing contributor to the project, and I'm not laughing, Rob. I'd be happy to discuss how to make the audit service optional.

From another direction, I think the analogy is really very weak. To compare a particular set of ontological commitments to a basic CRUD API (which is what LDP is for Fedora) is not even apples and oranges, it's apples and motorcycles. On the other hand, you're right that a full SPARQL endpoint over the whole repo is not something everyone wants or needs. That's why it _is_ optional.

Lastly, I've said before and I'll again now that the claim that a "blessed" model decorated with the official Fedora name and using Fedora resources will be simply ignorable by Fedora users just rings false to me, and what's more, it will become less ignorable over time.

---
A. Soroka
The University of Virginia Library

[Benjamin Armintor]

Rob-

I would have to check, but I'm fairly certain I have taken this stance about the audit service on the list, certain I've taken it on IRC. It's a conditioned reaction to what I see as the organizational struggles and implementation overreaches of FCR3, coming from the fact that the codebase was extremely difficult to maintain owing to limited participation and a large number of client promises. I'll be the first to acknowledge that my positions in this line are extreme, but I think it's necessary to grapple with them, over and over.

- Ben

[aj...@virginia.edu]

As someone who spent time dealing in the same codebase with the same issues of limited participation, a large number of client promises, and a dangerously monolithic architecture (and who is already seeing at least the first two of those problems already cropping up in Fedora 4), I don't think Ben's position is extreme at all.

There are features _currently in Fedora 4_ that I would be very happy to discuss modularizing, or if you like, "optional-izing". (E.g. RDF transformations and metrics, to start with.)

The relevance to the FCDM discussion is this: besides the choice to include (and maintain and support) some piece of work in Fedora itself and the choice simply not to do it, there are plenty of other choices. No one is claiming that this Hydra-Islandora effort is a bad thing. But the fact that it is a good piece of work for Hydra and Islandora (and perhaps eventually other agencies) to pursue does not automatically mean that it should be bunged into the bins with everything else that the Fedora project is expected to support.

---
A. Soroka
The University of Virginia Library

[Stefano Cossu]

Hi Rob,
I know this could hijack the conversation, so I will keep it on a general level.

As far as I understand, Fedora's goal is primarily to be a storage and preservation system. As such, all the features that the Fedora community (judiciously and by voting process such as for the blank nodes) considers part of this scope should be included in the core. If someone doesn't need them, they should be able to turn them off.

On one side, stuffing all kinds of features in the core will lead to an unmaintainable project. On the other side, offering a piecemeal system would put a burden on users, especially new adopters, who might get confused about what they have to install and how to put the pieces together.

A content model is definitely something different from an audit service and external to the aforementioned scope; I agree with the general line of thought so far about keeping it external.

Stefano Cossu
Director of Application Services, Collections

The Art Institute of Chicago
116 S. Michigan Ave.
Chicago, IL 60603
312-499-4026

[Tom Cramer]

Personally, while I think this effort is certainly a data modeling effort of great interest and promise to the Fedora Community, I think it's premature to call it "the Fedora Community Data Model"--as it's not yet baked, it's not yet proven in any implementation, and no matter how valiantly it is documented and communicated that it is an optional, reference implementation, there will certainly  there will certainly be those who will perceive it as prescriptive rather than descriptive, and who may end up walking away from Fedora or otherwise limiting their engagement because of it. 

While this may become the Fedora Community's de facto, common data model in time, I'd rather let the community vote with their feet by adoption rather than name it that now. 

+1 to renaming it (perhaps the Portland Data Model or the White Stag Data Model, based on the city/building where it blossomed?)

+1 on doing this work within & across the whole Fedora community

+1 on having DuraSpace host the necessary files & schema, or creating a neutral domain to resolve to wherever we host it

- Tom

[Eric James]

As a person just trying to understand that data model and trying to figure out user scope, wondering who else would use the model other than fedora (dspace? vivo? someone else).  That may or may not help in naming it. In any case I like Tom's suggestions "Portland Data Model" or "White Stag Data Model". We might not know where this is going but we sure know where it's from.  (Is that a Whitesnake song?).

-Eric

[Stefano Cossu]

Actually this discussion seems to be getting closer to the title of this work: http://tinyurl.com/n4kz3a8

+1 to Portland.

That said, I think Tom is not the only one trying to figure out user scope. Is this model meant to be as broad as possible (whatever that means)? Or is it going to make some assumptions that are useful to most of the Fedora / Duraspace user base, while who doesn't fit into it can just opt out?

I also think that a model that encompasses all of the Duraspace applications might become too broad for practical use. What if Fedora had its own extension that is aimed at the Fedora user base?

Stefano Cossu
Director of Application Services, Collections

The Art Institute of Chicago
116 S. Michigan Ave.
Chicago, IL 60603
312-499-4026

On 3/2/15 5:17 PM, Newman, Linda (newmanld) wrote:

Yep it might be a Whitesnake song https://www.youtube.com/watch?v=Ahf3ud0RUUA.   (Can’t believe I’m actually listening to it right now.)

 

+1 to Portland Data Model, and to Tom’s comments and suggestions.

 

-- Linda

--
You received this message because you are subscribed to the Google Groups "Hydra-Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hydra-tech+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Hydra-Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hydra-tech+...@googlegroups.com.

[Robert Sanderson]

Stefano, Ben, Adam, Joshua,

Thank you for the reasoned responses, and apologies if the original tone came across as inflammatory.  The intent was to gauge perspective against other ongoing work to see if the same reasoning would help us to move our respective points of view from what appeared to be a irresistible force versus immovable object, with no real way to resolve it.

I hope that the ends justify that particular means, as the feeling seems to have resonated with many, both on and off list. So ... deadlock resolved ... and now to work on a new name :) 

Best,

 

Rob

[Tom Cramer]

++ to Esme's points.  

It seems to me we're talking about patterns for structuring digital objects--"content modeling" in more traditional Fedora-speak--in RDF, in order to promote both code and data interoperability. As Adam points out, there is great flexibility in Fedora for content modeling, but in many cases this has led to needless redundancy in the Fedora community as countless sites have modeled very similar kinds of objects (like books, singleton images, maps) in (sometimes very slightly) different ways--lots of snowflakes! 

The hope of many in the Hydra community, shared by at least some Islandora and other Fedora users--is to put some upfront thought into how we model sets, items and their components as we move to F4 in such a way that to reflect best practices and meet the common needs of many sites, and avoid reinventing the wheel. 

I actually think the potential audience for the data model is much greater than the current Fedora or future DSpace communities; if we do this well, it has the potential to be of great interest to the entire LAM community, or any future RDF users who want well-considered ways to structure their content for internal systems, or with linked data on the open web. 

- Tom

On Mar 2, 2015, at 4:05 PM, Esmé Cowles wrote:

Stefano-

I think the model as it stands now is very general and flexible -- collections containing collections and objects, objects containing objects and files.  Agreeing on at least this level, and expressing these ideas using the same RDF vocabulary, will make it much easier for different tools to interoperate at the basic structural level.  This approach was guided by the fact that there was in fact disagreement and differing approaches to these things in the Hydra community, and at least overcoming this kind of needless incompatibility seemed very attainable.

But to get much more than that, we'll need to agree on much more specific and controversial things like descriptive and technical metadata vocabularies, access control approaches, etc.  I hope to continue discussions and develop approaches that let people have different decisions in some of these area while maintaining as much interoperability as possible.  So far, this is mostly a nebulous idea of developing a common pattern for handling RDF, based on nodes either being literals (relatively easy to handle) or URIs (which need standard ways to label them and choose what code to parse them with).

Suffice it to say that there's a lot of work to do, and I'm interested in everyone's ideas and input.

-Esme

On 03/02/15, at 6:44 PM, Stefano Cossu <sco...@artic.edu> wrote:

Actually this discussion seems to be getting closer to the title of this work: http://tinyurl.com/n4kz3a8

+1 to Portland.

That said, I think Tom is not the only one trying to figure out user scope. Is this model meant to be as broad as possible (whatever that means)? Or is it going to make some assumptions that are useful to most of the Fedora / Duraspace user base, while who doesn't fit into it can just opt out?

I also think that a model that encompasses all of the Duraspace applications might become too broad for practical use. What if Fedora had its own extension that is aimed at the Fedora user base?

Stefano Cossu

Director of Application Services, Collections

The Art Institute of Chicago

116 S. Michigan Ave.

Chicago, IL 60603

312-499-4026

On 3/2/15 5:17 PM, Newman, Linda (newmanld) wrote:

Yep it might be a Whitesnake song https://www.youtube.com/watch?v=Ahf3ud0RUUA.   (Can’t believe I’m actually listening to it right now.)

+1 to Portland Data Model, and to Tom’s comments and suggestions.

-- Linda

From: hydra...@googlegroups.com [mailto:hydra...@googlegroups.com] On Behalf Of Eric James

Sent: Monday, March 02, 2015 6:11 PM

To: fedor...@googlegroups.com

Cc: <hydra...@googlegroups.com>; islandora; Tom Cramer; fedora-...@googlegroups.com

Subject: [hydra-tech] Re: [fedora-tech] Fedora (?) Community Data Model

You received this message because you are subscribed to the Google Groups "Hydra-Tech" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hydra-tech+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Hydra-Tech" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hydra-tech+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Hydra-Tech" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hydra-tech+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Hydra-Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hydra-tech+...@googlegroups.com.

[Tom Johnson]

Sorry to be slow replying; I've been traveling this week.

On Fri, Feb 27, 2015 at 5:59 PM, Robert Sanderson <azar...@gmail.com> wrote:

Sorry, I need a little bit more help to understand the issue!

 

5.2.3.12 is pretty explicit that an LDP server MAY create an rdf source to hold the metadata about a non-rdf source, and if it does, then it MUST give the URI of that rdf source in the describedby link header.

The differences I've seen in implementations surround the class of the RDFSource and it's containment relationship, if any, to the NRSource.

  - Fedora: creates an LDP-NR source at `target-uri` and links it via describedby to `target-uri/fcr:metadata`. `fcr:metadata` (if I understand correctly) is not (cannot be?) a container.

  - Marmotta: creates an LDP-NR source at `target-uri.extension` and links it via desccribedby to `target-uri`. `target-uri` is a BasicContainer, containing `target-uri.extension`.

Both of these seem fine, as far as the spec is concerned but both come with their limitations.  Fedora's limitation re: containment gave rise to the hasRelatedFile workaround discussed below.  To bring the thread up to speed, that workaround is: 

  <coll1> fcdm:hasMember <object1> .
  <object1> fcdm:hasRelatedFile <fits1> ;
            fcdm:hasFile <thumb1>, <content1> .

 

Where `fits1` is a fits xml file describing `content1` and `hasRelatedFile` is a membership triple marking its containment in `object1`. The concerns I expressed previously are:

  - `object1`'s relationship with <fits1> is very direct in the model, while its actual relationship is mediated by `content1` (if content1 were to move to another object, for instance, the containment would be suddenly out of place). 

  - This will be hard (maybe not impossible) to implement in Marmotta because of the limitations of its approach to 5.2.3.12.

Thus a conservative client that wants to perform operations on the metadata about a non rdf source will do a HEAD request on the non rdf source, find the describedBy link, and then work with the target URI from there (either to retrieve, update, and so on).  A fedora specific client might (naughtily) assume that the metadata will be at uri-ldpnr/fcr:metadata which would not be correct for other implementations ... and hence a good implementation of the FCDM would not do that.

To get non RDF metadata associated with the file, you would simply need to update that resource with the relationship of how some non rdf source is related to the described non-rdf source.  LDP does not specify how to associate non rdf source directly with non rdf source, which seems very reasonable for a *Linked Data* Platform :)  To do so would likely be very use case specific.

 

And thus we need the hasRelatedFile workaround that the LDP document describes at a URI level, and the model includes (modulo our current discussion) at the abstract level.  This is why we need the model in the first place, so that we as a (self-selecting) community can agree upon the patterns we want to use within the rope given to us by the standards.

This is the concern I have exactly. We are seriously considering making modeling decisions (at the abstract level), based on a mapping to LDP that we've drawn in response to Fedora's specific behaviors.  I don't see why anyone not using Fedora would want to use the proposed `fcdm:hasRelatedFile` portion of the model.  

It's good that we're a self-selecting community; but there's a lack of clarity about whether we're a community that's building a model for Fedora users or more broadly.  To be blunt, when you say things like:

> s/require Fedora./require a good implementation of LDP./

I worry that we're at risk of selecting a lot of people out.

- Tom

--

-Tom Johnson

[Esmé Cowles]

Tom-

I think you make a really good point here that the fcdm:hasRelatedFile property is essentially taking a limitation of Fedora and baking it into the model. Maybe it makes more sense to just make related files their own works (with no relationship with the parent work at all), and link to them.

So you would have:

_:work1 fcdm:hasFile _:file1 (e.g. TIFF image)
_:file1 fcdm:hasTechnicalMetadata _:work2
_:work2 fcdm:hasFile _:file2 (e.g., FITS XML describing _:file1)

This avoid baking the Fedora limitation into the model, so it could be easily changed later on if the tech evolves, handled differently by different LDP implementations, etc.

-Esme

> To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
> To post to this group, send email to fedor...@googlegroups.com.
> Visit this group at http://groups.google.com/group/fedora-tech.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
> To post to this group, send email to fedor...@googlegroups.com.
> Visit this group at http://groups.google.com/group/fedora-tech.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
> To post to this group, send email to fedor...@googlegroups.com.
> Visit this group at http://groups.google.com/group/fedora-tech.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --

> Scott Prater
> Shared Development Group
> General Library System
> University of Wisconsin - Madison
>
>
> --
> You received this message because you are subscribed to the Google Groups "Fedora Tech" group.

[Benjamin Armintor]

As I understand our goals, the API for Fedora should be LDP or extensions to LDP that one could imagine being proposed to w3c. If there is a real Fedora-ism revealed by the PDM efforts, that sounds like a bug in Fedora. I know that this sounds like a reversal of some of my comments up thread, so let me make my stance explicit: Fedora should not explicitly support one data model, but it should support LDP data models that doesn't assume Fedora.

The PDM should model a way things ought to be; as Joseph and others point out, implementation may lag. If the difference between Fedora and Marmotta here indicates a flaw, let's file a ticket and fix it.

[Tom Johnson]

Thanks Esme. Your proposed structure seems like the natural one to me.

Ben: I'm not sure it does constitute a "bug" since the LDP spec is silent on the issue, but I do think Fedora would be improved if `fcr:metadata` nodes were slightly re-envisioned to more generally apply as "the RDFSource that provides a description of the NRSource"*.  The functional difference would be that that RDFSource could be a container (of any type?).

* some people probably already understand it this way, but I think others are thinking slightly more traditionally about "metadata".

- Tom

[Robert Sanderson]

I think that Marmotta is not doing the right thing here, and that Fedora is correct in its implementation. Here's my rationale:

* To create a non rdf source, you can POST it to a container.  The expected behavior is that the container POSTed to will then contain the new resource.

* In Marmotta, as I understand it, if you post a non rdf source to a container, it will create *another* container and then create the non rdf source within that.

This breaks the MUST of 5.2.3.2:

When a successful HTTP POST request to a LDPC results in the creation of a LDPR, a containment triple MUST be added to the state of the LDPC whose subject is the LDPC URI, whose predicate is ldp:contains and whose object is the URI for the newly created document (LDPR).

So my perspective, as far as the description given of the behavior, is that Marmotta does not correctly implement the LDP specification, as the LDPC will contain a new LDPC that contains the LDPR (in this case an LDP-NR, hooray for acronyms).

Thoughts?

Rob

[Tom Johnson]

Thanks Rob, 

At a first read, I don't see 5.2.3.2 as precluding Marmotta's behavior.  The POST does create a document as requested (LDPR) and it does add the membership triple pointing to that document to the original container. I haven't been able to find anything in LDP or other specs that describe POST/PUT behavior that says the created resource must exist at a particular URI in relation to the requested one, and this is where Marmotta's approach is counter-intuitive.

I think it is clear that the behavior is not ideal, but it doesn't seem broken according to any spec or clause that I can find.  I'd love to talk this out more, since I'm eager to present a knockdown case for a change to the Marmotta devs.  If I can put together a more complete description of Marmotta's behavior and how I think it compares to the spec, would you be willing to take a look before I start unleashing feature requests on Marmotta folks?

All of this is tangential to the issue with the workaround we've discussed.  A change in Marmotta would make it easier to implement the workaround there, but I'm still of the opinion that I wouldn't want to.  Does an Object necessarily has any relationship with a fits file that describes one of its member FIles?  I've not heard any reason for `hasRelatedFile` except that `fcr:metadata` nodes happen to not be containers (and presumably we want metadata files to be contained by something nearby).

- Tom

[aj...@virginia.edu]

Just on this particular point: "`fcr:metadata` nodes happen to not be containers" because from a historical point of view, they are the evolved form of the properties available on datastreams in older versions of the Fedora information architecture. Datastreams are fundamentally simple, though. They are just bitstreams with some properties (limited and explicitly-defined properties in older version, arbitrary properties in Fedora 4). They don't have any internal structure (from the point of view of the repository).

The idea of a datastream goes back to the very beginnings of the Fedora model, and the idea has always been that a datastream in a Fedora object is some kind of representation (hopefully a durable one) of the intellectual object which that Fedora object stands for. The classic example would be an object that represents a page of a manuscript, with a textual transcription and an image in two different datastreams. The canonical modeling approach ended up being that if you needed repository-visible structure inside your datastreams, the granularity with which you'd chosen your objects was not fine enough: make more objects with richer relationships between them and you wouldn't need structured datastreams.

So the idea of a datastream that is also a container is very much at odds with where Fedora has come from. Whether it is a good idea now is a completely different question, of course. I vaguely recall that at some point getting to 4.0 we opened that door and then shut it again, but whether that was out of fear, shock, boredom, or just tiredness I can't remember.

---
A. Soroka
The University of Virginia Library

[Adam Wead]

At the risk of increasing an already tangental discussion, I'm seeing some new questions here that are puzzling me.

While it was apparent to me before, after the discussion in Portland, we wanted the CDM to adhere to the LDP spec. I'm actually not sure if this has ever been explicitly stated. I originally thought this was an attempt to find a common model that fit existing Hydra implementations, but it is obviously a lot more than that! I have in my mind a Venn diagram with two circles that overlap. One is Fedora, the other is LDP, and the overlapping bit between them is our CDM.

So, the CDM fully adheres to the rules set forth in LDP, and can be fully implemented using Fedora. That leaves, however, Fedora to be "flexible" and do things not kosher with LDP, should you so choose. If you inject Marmotta into the mix, this is a third circle in the diagram. Ideally, our CDM could be implemented in Marmotta as well, but that's a whole other bag of tacks.

Do I have this right?

…adam

[aj...@virginia.edu]

One important point that I think you may have missed: Fedora 4 is an LDP implementation. That is, if there is any part of that LDP circle that is outside the Fedora circle, it's by design and it's unlikely to change. Mostly, the Fedora circle encloses the LDP circle.

For that reason I'm not sure that an independent common data model is actually needed or useful between Fedora 4 and LDP.

---

A. Soroka

the University of Virginia Library

[Esmé Cowles]

Adam-

I think you have that right. It was started as an attempt to increase interoperability among Hydra implementations, but with a focus on LDP from the beginning to make this work not just in Fedora, but also in Marmotta, or some other LDP platform.

There will probably be more issues with LDP implementations not being completely compatible with each other, but hopefully this will get worked out over time. And there is a lot of functionality in Fedora that's outside of the LDP spec, so getting cross-platform support for those features may be more difficult.

-Esme

[Robert Sanderson]

+1.

If there is available time and motivation, I'm happy to try and relay any cross-platform findings back to the W3C and/or act as a go-between to try and improve the consistency of implementations with the respective developers/product owners.

Also, another plug for the LDP workshop where (hopefully!) the developers of multiple implementations will be present so we can hash out at least the areas of concern face to face.

Rob

[aj...@virginia.edu]

I am very confused now and I can no longer perceive the value of the proposed CDM at all.

People implementing a data model over Fedora should have available all the non-optional facilities of LDP. If not, that is a bug in Fedora.

If people want to implement a data model using only LDP facilities in Fedora (for future cross-platform work), nothing is stopping them from doing that. Why is another data model in any way needed for that?

As a layer above LDP, which is a layer above Fedora, I can see the value of a CDM to the Hydra and Islandora communities, including for cross-platform work. As a "shim" between Fedora and LDP, it's not clear to me.

---

A. Soroka

the University of Virginia Library

[Esmé Cowles]

Adam-

I don't see anyone describing the PCDM as a shim between LDP and Fedora. It's a layer above LDP, which is a layer above both Fedora and Marmotta. Because there are people involved in the PCDM efforts using Marmotta, we're interested in compatibility of the model with Marmotta. But that doesn't change the role of the model at all.

-Esme

[aj...@virginia.edu]

Esme-

Your description jibes with my previous understanding. That's why I don't understand Adam Wead's proposed diagram, with this CDM taking part in both Fedora and LDP. By your description (and my previous understanding) it should live inside LDP, which lives inside Fedora. There should be no especial "overlapping bit" between Fedora and LDP to be filled by this CDM.

---

A. Soroka

the University of Virginia Library

[Esmé Cowles]

Adam-

Right -- Fedora is a complete LDP implementations, so LDP is contained entirely within Fedora. So Marmotta and Fedora is the typical Venn diagram, since they both implement different non-LDP features, but their intersection contains the LDP API.

-Esme

[aj...@virginia.edu]

Okay, good.

But that's not what Adam wrote, and that's why it confused me when you and Rob Sanderson agreed to his remarks:

"I have in my mind a Venn diagram with two circles that overlap. One is Fedora, the other is LDP, and the overlapping bit between them is our CDM."

As long as we're all clear that this proposed CDM lives above LDP and that it has no direct relationship with Fedora (no relationship, that is, unmediated by LDP) then I feel a lot better. Thanks, Esme.

---
A. Soroka

the University of Virginia Library

[Esmé Cowles]

Scott-

Let me echo what Tom said and say it's really good to hear that you see the FCDM as being generally agnostic and promising. That was the goal, and it's always good to get feedback on how well we're meeting it.

We've mostly focused on the structural metadata aspects so far, which I think is the most crucial for basic interoperability. But I think it'll be good to get some guidance for technical metadata about files, and descriptive metadata. Like the WebACL recommendation, I expect these won't be as widely accepted as the basic structure. But the more things we can agree on, the more interoperable our tools can be.

I would definitely be interested in hearing about why WebACLs won't work for you. Maybe additional tooling would make them usable for you? Or maybe there is another pattern we could add to the FCDM as a recommendation for people who can't use WebACL?

-Esme

> On 02/27/15, at 6:59 PM, Tom Johnson <johns...@gmail.com> wrote:
>
> Thanks Scott, for sharing your interest and perspective.
>
> It's heartening to hear, since the general applicability you ascribe to the model seems to be to have been it's foremost design goal.
>
> As your message suggests, there's little harm in continuing this collaboration under the heading of "Fedora" as long as we communicate well about the applicability of the model.
>
> I think our communication struggle is more likely to center on the messaging surrounding "Collections" and "Works"/"Objects" than Fedora. This is especially so since, in light of current issues surrounding LDP and the model's interpretation of it, significant portions of the model may in fact require Fedora.
>
> - Tom
>
> On Fri, Feb 27, 2015 at 2:09 PM, Scott Prater <scott....@wisc.edu> wrote:
> FWIW, we've started reviewing the FCDM here at the University of Wisconsin, with a view of migrating from our custom Fedora 3.0 content model implementation and applications (no Hydra, no Islandora) to Fedora 4 at some point in the future. What we've seen described on the FCDM page looks very promising, fairly agnostic in terms of the types of content being modelled (especially if you interpret the idea of "Collections" as a broader, abstract category), and doesn't smell of a particular architecture, software stack, or even type of user.
>

> As I understand it, the FCDM project may have arisen out of the needs and discussions of the Hydra and Islandora communities, but it is by no means applicable to just that subset of Fedora users; I think there's something there for everyone. Nor is it an all-or-nothing, take-it-or-leave it proposal -- institutions may see fit to adopt certain aspects of the model, but not others (WebACLs, for example, are unlikely to play any part in our objects). Nor is it fixed in time -- from what I've gathered, part of the purpose of the FCDM project is to move it beyond the Hydra and Islandora communities, evolve into something more general-purpose, make it something with that will be applicable to a variety of institutions and types of content (although, if our implementation happens to speak the same language as Hydra/Islandora applications, so much the better for interoperability).

>
> With all that in mind, Fedora seems to be the natural home for it, under the auspices of the Duraspace infrastructure. I take your point, though -- maintenance and discussion of a descriptive, best-practice but by-no-means-mandatory data model should be kept at arm's length from the work of the Fedora repository software; no carts should be placed in front of any horses.
>
> It may be useful to hear from other Fedora users that are not museums or libraries, to see what their reaction is to the FCDM.
>
> -- Scott
>
>
> On 02/27/2015 03:40 PM, aj...@virginia.edu wrote:
> I raised the objection, so let me fill it out a bit, starting from this point:
>
> "At that point, the common denominator was Fedora…"
>
> I can't agree. At this point, the common denominator is: those Hydra and Islandora institutions that have participated in this discussion. I'm personally not very clear how the discussion has proceeded or where it is expected to go, and I'm not sure how well-publicized we can consider it to have been to the broader Fedora community, but in any event, that broader community includes plenty of institutions that are using neither framework and I find it hard to believe that the communities around those frameworks have been perfectly represented by a meeting at code4lib and the other pieces of this discussion. Certainly, I may be very wrong.
>
> Part of the power (and longevity) of Fedora has come out of the ability it provides its community to experiment with sophisticated content modeling. This effort, while excellent in its own right, is specifically aimed at those institutions that choose to model their resources around library-ish concepts like "collections". That is a large portion of the Fedora community, but not all of it by a long ways.
>
> As for an appropriate home for this effort: that's up to the Hydra and Islandora communities. I think them more than capable of shouldering the burden.
>

> ---
> A. Soroka
> The University of Virginia Library
>

> ---
> A. Soroka
> The University of Virginia Library
>

> On Feb 27, 2015, at 12:41 PM, "Cowles, Esme" <esco...@ucsd.edu> wrote:
>
> - The other issue is related to the hasMember and aggregates properties. In the discussions after code4lib, we decided to make fcdm:hasMember a sub-property of dcterms:hasPart instead of ore:aggregates, to avoid problems trying to find aggregated resources separate from members. Rob rightly noted that the ore:Proxy membership requires the predicate to be a sub-property of ore:aggregates, so I've changed that back. I believe people can still find aggregated and member resources separately, but I want to ask if anybody has any concerns about this.

> --
> You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
> To post to this group, send email to fedor...@googlegroups.com.
> Visit this group at http://groups.google.com/group/fedora-tech.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
> To post to this group, send email to fedor...@googlegroups.com.
> Visit this group at http://groups.google.com/group/fedora-tech.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
> To post to this group, send email to fedor...@googlegroups.com.
> Visit this group at http://groups.google.com/group/fedora-tech.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --

> Scott Prater
> Shared Development Group
> General Library System
> University of Wisconsin - Madison
>
>

> --
> You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
> To post to this group, send email to fedor...@googlegroups.com.
> Visit this group at http://groups.google.com/group/fedora-tech.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --

> -Tom Johnson

[Newman, Linda (newmanld)]

Yep it might be a Whitesnake song https://www.youtube.com/watch?v=Ahf3ud0RUUA.   (Can’t believe I’m actually listening to it right now.)

 

+1 to Portland Data Model, and to Tom’s comments and suggestions.

 

-- Linda

 

From: hydra...@googlegroups.com [mailto:hydra...@googlegroups.com] On Behalf Of Eric James
Sent: Monday, March 02, 2015 6:11 PM
To: fedor...@googlegroups.com
Cc: <hydra...@googlegroups.com>; islandora; Tom Cramer; fedora-...@googlegroups.com
Subject: [hydra-tech] Re: [fedora-tech] Fedora (?) Community Data Model

 

As a person just trying to understand that data model and trying to figure out user scope, wondering who else would use the model other than fedora (dspace? vivo? someone else).  That may or may not help in naming it. In any case I like Tom's suggestions "Portland Data Model" or "White Stag Data Model". We might not know where this is going but we sure know where it's from.  (Is that a Whitesnake song?).

 

-Eric

--
You received this message because you are subscribed to the Google Groups "Hydra-Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hydra-tech+...@googlegroups.com.

[aj...@virginia.edu]

Tom and Esmé are raising some really important ideas here. I'd like to unpack some of them a little.

Content modeling, in previous Fedora work, certainly did include ideas of modeling structure for digital resources, and more. (Also included were ideas of modeling _behavior_ for digital resources. Several times the open question as to how Fedora 4 will deal with that kind of work has been raised on this list and in other fora. But we don't have to deal with both kinds of modeling at once.)

The practice of Fedora, it seems to me, has three-ish moves in it:

1) Determine and define the intellectual quanta in which your repository is going to transact. These will be the durable packages of your material. They are encoded as your Fedora objects. The boundaries of those Fedora objects outline regions of content that have intellectual coherence on their own, and which we wish to make durable.

2) Make and publish your ontological claims about those intellectual objects and their relationships. This, in practical work, is now done by embedding your Fedora objects in a graph (an RDF graph) that provides them context and thus provides a first portion of durability for the underlying intellectual objects. Previously we did this by adding descriptive records as datastreams in the Fedora objects, and that will continue to be common for some time to come, but the clear direction is towards embedding in a graph.

3) Make and publish durable representations of the content of those intellectual objects as datastreams in your Fedora objects. This is how they acquire the other portion of their durability.

4) Many people have used the behavior-modeling abilities of the CMA to go one last step: make and publish durable representations of the behavior of those intellectual objects.

(While Tom mentioned content modeling as a tool for interoperability, I'm obviously more concerned here with content modeling as a practice that support durability.) The first two kinds of work above are essentially what we do when we create ontologies (e.g. for publication in the Semantic Web). So it's not surprising that in Fedora 4, much of what Tom called "patterns for structuring digital objects" appear as OWL or RDFS.

Tom and Esmé raise a good point: without _any_ coherence or sharing between content modelers, we get a lot of wasted time and effort. It's true. What's not obvious to me is that the right solution to that problem is to share a uniform "upper ontology". In fact, one of the most powerful advantages of the move from Fedora-specific modeling languages to more widely-used languages like OWL and RDFS is the possibility that repositories might share their content modeling, not with other repositories, but with the domain-communities they actually serve. For example, a repository (or section thereof) holding digitized specimens from a herbarium might be organized according to the Plant Ontology, or a repository holding images of coins might be organized by Nomisma categories. It's not clear to me (in fact, I'm becoming increasingly sure that it is not the case) that selecting for a particular ontology based on tool reuse is actually a good way to use Fedora. In any event, if that _is_ the way folks want to build their repositories, then proposing a shared upper ontology (across the Fedora community) seems to me to be a little premature at this time. Fedora 4 has been in production for only a few months, and I would to learn a great deal more from the experiences of people who migrate richly-modeled Fedora 3 repositories to Fedora 4. (Of course, that just doesn't apply to the Hydra and Islandora communities, each of which already shares internally a great deal in common in their content modeling because it's been driven by their tool selection.)

---
A. Soroka
The University of Virginia Library

[Joshua Westgard]

I agree with what Tom and Stefano have said in this regard. We are very interested in the Community Data Model, and there's a reasonably good chance we'll adopt it, but I see no reason why it needs to become a part of the core, or even the defacto standard.

Josh

--
Joshua A. Westgard, MLS, PhD
Systems Librarian, Digital Programs
Digital Systems and Stewardship Division
University of Maryland Libraries

[aj...@virginia.edu]

I don't agree at all that the two classes of things are analogous.

The former are components that are entirely supported by the Fedora community and without that community, there would be neither need for nor interest in them. What's more, and more important, there is no reason to suppose that they are drawing efforts away from any other attempts at solutions to the problems with which they concern themselves. The latter, this new effort under discussion, is specific to the Hydra and Islandora communities and not only do they have their own resources to bring to bear on the work, there is (as I mentioned before) every reason to think that an effort like this, if "blessed" with a Fedora imprimatur, will draw resources away from other possible efforts at content modeling.

---
A. Soroka
The University of Virginia Library

On Feb 27, 2015, at 5:14 PM, Esmé Cowles <esco...@ticklefish.org> wrote:

> Adam-
>

> I really don't understand how this is different in any way from the other optional components hosted in the Fedora github organization and documented in the Fedora wiki. The Fedora project hosts two different authentication implementations, and two separate message processing platforms, for example, that many people in the community don't use. But I have no objection to them using the Fedora github/wiki.
>
> The data model seems very analagous to me: an effort by a subset of the Fedora community, that is related to Fedora but not tightly bound. It seems entirely appropriate to use the Fedora project resources for this.
>
> -Esme
>
>> On 02/27/15, at 5:03 PM, aj...@virginia.edu wrote:
>>
>> I think we're talking "at two different angles", Andrew.
>>
>> I agree that those are important questions for this effort. I don't agree that they are the responsibility of the Fedora community, because I don't agree that this effort is the responsibility of the Fedora community, and that's the root of my objection.
>>
>> I appreciate your point about the nature of a reference model. I think you'll agree that it would be disingenuous to claim that the existence of a "reference model" will not stifle the flow of resources to other modeling efforts. If that were not the case, then we would have many different widely-available Fedora Commons implementations from which to choose today, instead of one "reference implementation".

>>
>> ---
>> A. Soroka
>> The University of Virginia Library
>>

>> On Feb 27, 2015, at 4:58 PM, Andrew Woods <awo...@duraspace.org> wrote:
>>
>>> Hello Adam,
>>> My suspicion is that if this ontology/work were to be termed "Islandora Community Data Model", it would alienate non-Islandora installations. Likewise, if it were to be termed "Hydra Community Data Model". There is both the question of what is the effort named? as well as under what namespace is it hosted?
>>>
>>> The most viable candidate yet on the table is:
>>> - Fedora Community Data Model
>>> - http://fedora.info/definitions/v4/models#
>>>
>>> I do not think that anyone is suggesting that the principles offered in the FCDM are the *only* way of modeling data in Fedora, but rather a strong reference model around which the greater repository community can develop a shared understanding.
>>> Andrew
>>>
>>> On Fri, Feb 27, 2015 at 4:41 PM, aj...@virginia.edu <aj...@virginia.edu> wrote:
>>> On Feb 27, 2015, at 4:28 PM, Robert Sanderson <azar...@gmail.com> wrote:
>>>
>>>> Requirements would be:
>>>> * Space for publishing
>>>> * Space for communication
>>>> * Clear licensing/IPR requirements
>>>> * Ability to participate without significant cost
>>>> * Organization is responsive to requests
>>>> * Provide a stable home
>>>
>>> You don't consider the Hydra and Islandora communities to fulfill these characteristics?

>>>
>>> ---
>>> A. Soroka
>>> The University of Virginia Library
>>>
>>>

>>>> Rob

>>>>
>>>>
>>>> On Fri, Feb 27, 2015 at 1:23 PM, Andrew Woods <awo...@duraspace.org> wrote:
>>>> Thanks for starting the thread, Esmé.
>>>>
>>>> I do not want to lose track of your first question:
>>>>>> - There was an objection to including the FCDM ontology in the fcrepo4 ontology repo and namespace, and a suggestion that somewhere less closely tied to fcrepo4 would be more appropriate. I know there are some people who are interested in the model using other platforms, so that could be a good move. Does anybody have an alternative to suggest? http://opaquenamespace.org/model# ?
>>>>
>>>> Initially the FCDM work was falling under the Hydra namespace. Then it became clear that the FCDM also resonated with Islandora and custom Fedora installations. At that point, the common denominator was Fedora, and hence the proposal to host the FCDM ontology under a Fedora namespace.
>>>>
>>>> If there is a more appropriate hosting namespace to use, let's get it on the table. Obviously the sooner that is agreed upon, the less potential downstream impact. In the absence of an alternative and from the candidates on the table, Fedora may be the best option.
>>>>
>>>> Suggestions requested.
>>>> Andrew
>>>>
>>>>
>>>>
>>>> On Fri, Feb 27, 2015 at 1:14 PM, Stefano Cossu <sco...@artic.edu> wrote:
>>>> Esmé,
>>>>
>>>> I find it more suitable to look at the relationship in logical terms: if fcdm:hasMember is logically a sub-property of ore:aggregates, why shouldn't it be defined as such? You can still formulate a query that searches for aggregates and excludes members.
>>>>
>>>> I am saying this because we plan on using a reasoner in our triplestore index, but I don't find this to be an issue.
>>>>

>>>> Stefano Cossu
>>>> Director of Application Services, Collections
>>>>
>>>> The Art Institute of Chicago
>>>> 116 S. Michigan Ave.
>>>> Chicago, IL 60603
>>>> 312-499-4026
>>>>
>>>>

>>>> On 2/27/15 11:53 AM, Esmé Cowles wrote:
>>>> Adam-
>>>>
>>>> It is indirectly since ore:aggregates is a sub-property of dcterms:hasPart. I think the issue that was expressed was that both relationships derived from ore:aggregates and so queries based on ore:aggregates would find both, therefore making it hard to find aggregated resources but not members.
>>>>
>>>> But thinking about that now, I think that would only be an issue in an environment with reasoning enabled, and that in fcrepo4 and any non-reasoning triplestore, that wouldn't happen. So I'm mostly asking if I'm remembering the issue clearly, or if there is some other issue with the fcdm:hasMember being a sub-property of ore:aggregates.
>>>>
>>>> -Esme
>>>>
>>>> On 02/27/15, at 12:45 PM, aj...@virginia.edu wrote:
>>>>
>>>> I may very well be misunderstanding this issue, but why cannot fcdm:hasMember be a subproperty of both?
>>>>

>>>> ---
>>>> A. Soroka
>>>> The University of Virginia Library
>>>>

>>>> On Feb 27, 2015, at 12:41 PM, "Cowles, Esme" <esco...@ucsd.edu> wrote:
>>>>
>>>> - The other issue is related to the hasMember and aggregates properties. In the discussions after code4lib, we decided to make fcdm:hasMember a sub-property of dcterms:hasPart instead of ore:aggregates, to avoid problems trying to find aggregated resources separate from members. Rob rightly noted that the ore:Proxy membership requires the predicate to be a sub-property of ore:aggregates, so I've changed that back. I believe people can still find aggregated and member resources separately, but I want to ask if anybody has any concerns about this.

[Adam Wead]

Sorry, folks, I seem to have troubled the waters.  Adam, please don't let my lack of understanding confuse you!

The mistake I made was thinking there were bits of LDP *not* available in Fedora. I get it now: Fedora does everything in LDP, and everything in LDP you can do in Fedora. However, Fedora has non-LDP bits. Marmotta, just like Fedora, can do all of LDP too, but its non-LDP bits differ from Fedora's LDP bits.

…adam

[aj...@virginia.edu]

No apology needed. I'm glad we got to better understanding all around.

I'll let the several folks more expert than am I with LDP correct me, but I think there are some optional things in LDP that Fedora does not do, either by choice or because of the expense of implementation. I'm not familiar enough with Marmotta's LDP implementation to comment on that point for them.

---

A. Soroka

the University of Virginia Library

[Andrew Woods]

Hello All,

This thread has raised some important, interesting, unexpected, and fruitful points. Please continue the conversation.

I would like to bring together inputs from many angles in proposing a resolution to the outstanding questions of: 

"What should this effort be named"? and 

"Where will the ontology be hosted and published"?

I believe we can agree on the following:

a) Name the effort: "Portland Common Data Model" (PCDM)

b) Host the code/ontology in a neutral DuraSpace GitHub organization: https://github.com/duraspace/pcdm

c) Publish ontology to project-independent server (likely offered by DuraSpace) with appropriate domain name (pcdm.org)

Does that sound appropriate and reasonable?

Regards,

Andrew

[Tom Johnson]

+1 to all of the above. Thanks Andrew.

--
You received this message because you are subscribed to the Google Groups "Hydra-Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hydra-tech+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

-Tom Johnson

[Robert Sanderson]

Ditto :)

[aj...@virginia.edu]

+1 indeed.

---

A. Soroka

the University of Virginia Library

You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.

[Michael J. Giarlo]

+1

-Mike

[Newman, Linda (newmanld)]

+1

-- Linda

[Benjamin Armintor]

+1

[nick ruest]

+1 to all 3

On 5 Mar 2015 19:17, "Andrew Woods" <awo...@duraspace.org> wrote:

Hello All,

This thread has raised some important, interesting, unexpected, and fruitful points. Please continue the conversation.

I would like to bring together inputs from many angles in proposing a resolution to the outstanding questions of: 

"What should this effort be named"? and 

"Where will the ontology be hosted and published"?

I believe we can agree on the following:

a) Name the effort: "Portland Common Data Model" (PCDM)

b) Host the code/ontology in a neutral DuraSpace GitHub organization: https://github.com/duraspace/pcdm

c) Publish ontology to project-independent server (likely offered by DuraSpace) with appropriate domain name (pcdm.org)

Does that sound appropriate and reasonable?

Regards,

Andrew

--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.

[Aaron Coburn]

+1

Thanks Andrew!

> You received this message because you are subscribed to the Google Groups "Hydra-Tech" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hydra-tech+...@googlegroups.com.

[Scott Prater]

+1

-- Scott

[Tom Cramer]

+1

Typed with my thumbs.

[Jon Stroop]

Yup.

-Js

[Robin Lindley]

+1!

Robin Ruggaber

[Stefano Cossu]

+1

Stefano Cossu
Director of Application Services, Collections
The Art Institute of Chicago

116 S Michigan Ave.
Chicago, IL 60603
+1-312-499-4026
sco...@artic.edu

[pcgo...@wisc.edu]

+ 1

- Peter Gorman