Define opposite of #PreferInboundReferences

[azaroth42]

Sorry for tossing this over the wall and running ... but ... would it be possible to define the opposite of http://fedora.info/definitions/fcrepo#PreferInboundReferences (one imagines #PreferOutboundReferences) for use with omit?

Then if the client wanted only the inbound references because it has already requested the outbounds with a regular request, the API would support:

Prefer:
   return=representation;
   omit="http://fedora.info/definitions/fcrepo#PreferOutboundReferences";
   include="http://fedora.info/definitions/fcrepo#PreferInboundReferences"

[zimeon]

What is the use case for this optimization? I see it in the abstract but am struggling to see the compelling practical use case.

Aside from that, I think the notion of outbound references being opposite to inbound references is not true in the sense that they are being used with return=representation. First, there are data property triples that are neither inbound nor outbound. Should one also have a ...#PreferDataProperties? I suppose triples with blank nodes (in implementations that support them) would be another wrinkle that don't make sense to include without including triples for a given blank node. Second, the current "SHOULD support http://fedora.info/definitions/fcrepo#PreferInboundReferences" is the only truly non-local request in the Fedora API spec -- it asks for triples from any other resource in the LDP server that references the context resource. In contrast, the proposed http://fedora.info/definitions/fcrepo#PreferOutboundReferences is a subset of the triples in the context resource and thus simply an optimization (like the LDP http://www.w3.org/ns/ldp#PreferContainment etc.). Third, the LDP classes of triple to include/omit are a bit fuzzy and I think there would be an odd overlap between outbound references and containment and membership triples, and some content triples. There would likely need to be work on some sensible and consistent definitions and the expected interactions between different include/omit.

[azaroth42]

Use Case

To scope in terms of PCDM (though the same holds true for practically every other partitioning construction), if there is a Book that has many Pages, the direction of the predicate in the information management system is likely to be Page is_part_of Book. The Book will have a lot of information as well, besides the long list of Pages. So ...

If you care only about the Book, and not the information about the individual Pages (such as a search result), then requesting only OutboundReferences (the default) is useful. If you care about everything at once, then you can add include=InboundReferences. However if you only want the list of InboundRefs (e.g. the page list to construct a thumbnail strip) you have to get the entire information about the Book as well. By requesting include=Inbound;omit=Outbound, you would get only the inbound references, thereby fulfilling the use case.

Issue 1

I agree that data properties are different from annotation and object properties (obviously), but in terms of the core RDF model, I don't think there's a significant difference for this use case. The default case (OutboundProperties) is all predicates that are defined that have the resource as subject, and the inverse is all predicates that are defined that have the resource as object. That can only be relationships, as literals cannot be the subject of triples in RDF 1.1. So ... I think InboundReferences and OutboundReferences are parallel, even if OutboundReferences include triples with both literals and resources as object.

Issue 2

I agree that OutboundRefs is an optimization. It's just defining a name for the default case, such that it can be used explicitly rather than only via the API as a default.

Issue 3

Isn't this also true for inbound? If there is a server managed triple (SMT) that creates a relationship between a resource and its creating user, then there is an inbound SMT. Indirect containers also create a bunch of triples that might otherwise be just regular triples. So I agree there is an issue to be discussed, but I disagree that it is unique to OutboundRefs.

[azaroth42]

And on a practical point, we need this functionality and would prefer an integrated solution, but of course we can define our own Prefer URI if its not a Fedora concern.

[barmintor]

There may also be a sticking point about blank nodes here as a set of statements for which the resource identifier is neither the the subject nor the object?

[azaroth42]

I think blank nodes are by definition excluded, as they cannot be referenced outside of their own document. That would also be an issue for InboundReferences though, no?

[acoburn]

For the use case above would this not suffice?

Prefer: return=representation;
    include="http://fedora.info/definitions/fcrepo#PreferInboundReferences";
    omit="http://www.w3.org/ns/ldp#PreferMinimalContainer http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferContainment"

Or would the purpose of #PreferOutboundReferences be syntactic sugar for the example above?

I can say that blank nodes are definitely an issue for #PreferInboundReferences. And any implementation that does not enforce a single-subject-restriction will also find this problematic for cases where the subject does not align with the resource URL. Those are two reasons why Trellis does not support #PreferInboundReferences at all (and wouldn't support #PreferOutboundReferences either).

[zimeon]

Although the semantics of including both omit and include are ill-defined (case not mentioned in either RFC7240 or LDP, I agree with @acoburn's #392 (comment) above that include="...#PreferInboundReferences"; omit="all three LDP prefs == all of normal LDPC response" would, depending upon the implementation, meet @azaroth42's use case in #392 (comment) .

If we wanted to make sure of the "depending upon the implementation" part we could make the specification more explicit to say that the extra include preferences SHOULD be interpreted independently of any of the LDP include/exclude preferences. However, my sense is that we have so far avoided being that prescriptive and these are only SHOULD/MAY requirements anyway.

[barmintor]

Given @acoburn's and @zimeon's insights here, I think we're inclined to defer here, unless @azaroth42 feels like there's a thread here that should be specified (or maybe addressed in a non-normative note?). Wading into the combinations of include and omit for the Prefer values seems outside the scope of the spec document.

[escowles]

Decision in 10/31/18 editor's call: We think this is addressed by the recipe in #392 (comment). Closing this issue.