Committer Vote Requested: Fedora4 and blank nodes

[Andrew Woods]

Hello Committers,

There has been considerable discussion of Fedora 4's support for blank nodes. The proposal outlined below has captured the various comments into a suggested implementation plan.

Please vote with a +1, 0, or -1 for your support of the proposed approach. Before moving forward with the implementation, we are looking for three or more binding +1 votes, and no vetos (-1).

Voting will be closed this Friday (2/27).

Thanks,

Andrew

p.s. Non-binding votes from interested stakeholders are also encouraged!

See related thread: https://groups.google.com/d/msg/fedora-tech/w1mQbJ03cS0/YWSsT1iFhrQJ

On Mon, Feb 23, 2015 at 11:20 AM, Aaron Coburn <aco...@amherst.edu> wrote:

Hi, Folks,

On last Thursday's tech call, we discussed the issue of blank nodes and came to a consensus about how fedora ought to handle them [1].

With that in mind, below is a proposal for what that would entail:

1) The REST API would continue to accept RDF documents with blank nodes (this is not a change from the current behavior).

2) The fedora:Blanknode class in the fedora ontology would be eliminated.

3) Blank nodes will no longer be published at the .well-known/genid location.

That is, when RDF documents with blank nodes are added to fedora, those blank nodes would remain anonymous and not be made available at any skolemized location. This change would not prevent clients from skolemizing blank nodes before adding them to fedora, but unlike the current behavior, it would not do so automatically.

4) When fedora:Container nodes are requested, any blank nodes contained in that document will be serialized as blank nodes, according to the concrete RDF syntax that is generated.

5) When a fedora:Container (one that contains blank nodes) is deleted, the corresponding blank nodes will also be removed from fedora.


Andrew,
I believe you suggested that this proposal would require a committer vote. If this proposal is in line with what we discussed last week, I will turn things over to you for a vote.

Regards,
Aaron

[1] https://wiki.duraspace.org/display/FF/2015-02-19+-+Fedora+Tech+Meeting

[Esmé Cowles]

+1 - I think this preserves support for blank nodes required by some users, and removes the unexpected skolemization that was problematic.

-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.

[Michael J. Giarlo]

A hearty non-binding +1 from me.

-Mike

[Nick Ruest]

+1 (non-binding)

-nruest

> --
> 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

> <mailto:fedora-tech...@googlegroups.com>.

> To post to this group, send email to fedor...@googlegroups.com

> <mailto:fedor...@googlegroups.com>.

[Robert Sanderson]

Non binding interested voter:

On Mon, Feb 23, 2015 at 9:23 AM, Andrew Woods <awo...@duraspace.org> wrote:

1) The REST API would continue to accept RDF documents with blank nodes (this is not a change from the current behavior).

+1

 

2) The fedora:Blanknode class in the fedora ontology would be eliminated.

+1

 

3) Blank nodes will no longer be published at the .well-known/genid location.

+1 to this as written ...

 

That is, when RDF documents with blank nodes are added to fedora, those blank nodes would remain anonymous and not be made available at any skolemized location. This change would not prevent clients from skolemizing blank nodes before adding them to fedora, but unlike the current behavior, it would not do so automatically.

... but this expansion is not what 3) says by itself.

As far as I understand it, it *would* prevent skolemization because Fedora will reject a node that refers to a resource in the repository that doesn't exist, rather than creating it.  Unless this would also be changed?

If a resource is created that has a URI already, doesn't Fedora assign a new URI to it?  So this would be inconsistent between re-identifying resources with URIs but not giving identifiers to blank nodes?

So can the proposal be expanded such that the "would not prevent clients from skolemizing blank nodes" be stepped through in practice?

4) When fedora:Container nodes are requested, any blank nodes contained in that document will be serialized as blank nodes, according to the concrete RDF syntax that is generated.

+1

 

5) When a fedora:Container (one that contains blank nodes) is deleted, the corresponding blank nodes will also be removed from fedora.

+1

Rob

 

Andrew,
I believe you suggested that this proposal would require a committer vote. If this proposal is in line with what we discussed last week, I will turn things over to you for a vote.

Regards,
Aaron

[1] https://wiki.duraspace.org/display/FF/2015-02-19+-+Fedora+Tech+Meeting

--

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.

--

Rob Sanderson

Information Standards Advocate

Digital Library Systems and Services

Stanford, CA 94305

[Stefano Cossu]

+1 non-binding - we will try to stay away from them, but if other institutions need them for legacy migration, I am in favor.

Stefano Cossu
Director of Application Services, Collections

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

--

[aj...@virginia.edu]

Rob makes a good point below:

On Feb 23, 2015, at 12:42 PM, Robert Sanderson <azar...@gmail.com> wrote:

> That is, when RDF documents with blank nodes are added to fedora, those blank nodes would remain anonymous and not be made available at any skolemized location. This change would not prevent clients from skolemizing blank nodes before adding them to fedora, but unlike the current behavior, it would not do so automatically. ... but this expansion is not what 3) says by itself. As far as I understand it, it *would* prevent skolemization because Fedora will reject a node that refers to a resource in the repository that doesn't exist, rather than creating it. Unless this would also be changed? If a resource is created that has a URI already, doesn't Fedora assign a new URI to it? So this would be inconsistent between re-identifying resources with URIs but not giving identifiers to blank nodes? So can the proposal be expanded such that the "would not prevent clients from skolemizing blank nodes" be stepped through in practice?

I think we may have some confusion about how the term "skolemization" is being used. As I understood it, Aaron meant to say that one may "manually" skolemize _before issuing a given request to the LDP API_ by pre-creating all those new Fedora-named entities to which Rob refers above. But Rob understood the term to mean that the repository will in fact create those entities automatically _on the issuance of the request to the LDP API_, which, as he points out, is definitely not true, at least not now. In an absolute sense, "skolemization" really just means the mapping from blank nodes to URIs (which is secretly between existential qualifiers and constants), so I suppose both uses are okay, but we need to understand when a given use is meant.

If that is an accurate picture of the confusion, then indeed some semi-narrative description of expected workflows should surely clear it up.

---
A. Soroka
The University of Virginia Library

[Esmé Cowles]

I agree this is an important distinction, and this sounds like a feature request to me: The current behavior requires pre-creating all of the resources you want to describe, and it would be convenient to remove that limitation.

A related issue is that the resources described have to be in the repository URI-space, and triples about other subjects are silently ignored now (see https://jira.duraspace.org/browse/FCREPO-1361).

These issues seem somewhat separate from the blank node functionality, though obviously related.

-Esme

[Robert Sanderson]

Let me go back to some fundamentals. Please stop me when you disagree...

1. Clients should not assign URIs as they do not control them.

2. There is no rule two.

3. See Rule 1.

:)

In other words, you need to create every formerly-blank-node as a real resource in advance of creating the top level, such that Fedora can assign a URI to the resource.

So when you have two formerly-blank-nodes that refer to each other ... now what?

Hence, can someone please walk through the steps with some non-trivial example of a client "skolemizing" its own blank nodes?

Rob

[aj...@virginia.edu]

I'm not sure I see the problem? Let's take:

<foo> <propertyX> _:a
<foo> <propertyY> _:b

with

_:a <propertyZ> _:b

and

_:b <propertyW> "A value."

The steps would be:

1) Create _:b, receiving <bar> as a repository-controlled URI as a result.

2) Create _:a, using <bar> instead of _:b, receiving <baz> as a repository-controlled URI as a result.

3) Create <foo>, using <bar> and <baz> in the obvious way.

Or am I misunderstanding the question?

---
A. Soroka
The University of Virginia Library

[Andrew Woods]

Hello All,

I would rather we not side-track the basic proposal at hand on account of the confused #3. 

Based on the discussion during last week's Fedora Tech Meeting [1], my understanding of the final clarifying sentence in the proposal's point #3 is that users would still have the option to remove the blank node structures from source RDF prior to ingest. I do not think it was any more complex than that. Regardless, I do not think Fedora would be able to support any specialized functionality beyond that.

I believe we can *remove* the following sentence from the proposal:

"This change would not prevent clients from skolemizing blank nodes before adding them to fedora, but unlike the current behavior, it would not do so automatically."

Andrew

[1] https://wiki.duraspace.org/display/FF/2015-02-19+-+Fedora+Tech+Meeting

[Egbert Gramsbergen]

+1, with the understanding that where it says rdf:Container probably rdf:Collection is meant.

Egbert Gramsbergen

-----Original Message-----
From: fedor...@googlegroups.com [mailto:fedor...@googlegroups.com] On Behalf Of aj...@virginia.edu
Sent: maandag 23 februari 2015 19:27
To: fedor...@googlegroups.com
Subject: Re: [fedora-tech] Committer Vote Requested: Fedora4 and blank nodes

[aj...@virginia.edu]

If you mean to discuss "fedora:Container", that is exactly what was meant. See:

https://github.com/fcrepo4/ontology/blob/master/repository.rdf#L678

---
A. Soroka
The University of Virginia Library

[Benjamin Armintor]

+1 to the proposal and to removing the sentence.

Also: Boo, blank nodes. Boo!

[Aaron Coburn]

Andrew,

Thanks for that suggestion. Yes, please remove that sentence from the proposal.

Aaron

[Egbert Gramsbergen]

Sorry, I read too fast. rdf:Container instead of fedora:Container.

[aj...@virginia.edu]

I'm still not sure that we're on the same page. Unless I misunderstand the proposal here, fedora:Container is certainly what is meant. This is not a matter of RDF semantics, but of LDP implementation.

---

A. Soroka

the University of Virginia Library

[Aaron Coburn]

The proposal refers to fedora:Container classes, and that is precisely what was meant.

--Aaron

Aaron Coburn
System Administrator / Programmer
Web Services, Amherst College

[Andrew Woods]

Yes, Adam (and Egbert), "fedora:Container" is the correct term in the proposal.

Andrew

[Andrew Woods]

Hello All,

To tie up this thread, the required number of affirmative committer votes have been collected and no vetos were submitted. Implementation of anonymous blank nodes within Fedora will proceed (thanks, Adam!) per this ticket:

https://jira.duraspace.org/browse/FCREPO-1385

Regards,

Andrew

[Tom Johnson]

I'm a big (non-binding) +1 on this.

> I agree this is an important distinction, and this sounds like a feature request to me: The current behavior requires pre-creating all of the resources you want to describe, and it would be convenient to remove that limitation.

This is indeed a feature I would request.  This, to me, is the crux of the "RDFSource" idea.  I should be able to POST/PUT a graph  to the system under the heading of an `ldp:RDFSource` and retrieve that graph from the RDFSource's URI, regardless of the contents of the graph..  The change with respect to bnodes seems like a major step in the right direction.

- Tom

-Tom Johnson