Page tree
Skip to end of metadata
Go to start of metadata

This page presents straw man data models for objects that may not need Linked Data Platform Containers (LDPCs).

The defining characteristics of this class of objects:

  • They do not contain bitstreams, but rather, metadata about bitstreams held elsewhere
  • They may contain pointer(s) to the referenced bitstreams (or bitstream objects)

The related concept in LDP (Linked Data Platform) terms:  Non-LDPC LDPRs

 

Background: LDP and its mapping to Fedora objects

The LDP specification lays out the following concepts, interaction modes, and constraints on content:

LDP ConceptLDP Interaction ModesConstraints on Content
Container (LDPC)LDPC, LDP-RSRDF, must contain LDP membership triples for all members
Non-RDF Source (LDP-NR)LDPR, LDP-NRnone
Non-Container RDF Source (LDP-RS-NC)LDPR, LDP-RSRDF

The last concept "Non-Container RDF Source" isn't given a specific name in the LDP spec, so we call it an LDP-RS-NC for the sake of discussion.

The defining characteristics of the interaction modes described in LDP are briefly summarized as follows

  • LDPC interaction mode defines ability to create resources within the container via HTTP POST, remove them via HTTP DELETE, and places requirements on the HTTP headers of the LDPC resource to advertise its role as a container.
  • LDPR interaction mode does not imply the creation new resources with HTTP POST on an LDPR
  • LDP-NR interaction mode implies POST, PUT, and PATCH do not have any special semantics; a resource is nothing more than a binary blob with a media type
  • LDP-RS interaction mode implies that POST, PUT, GET, and PATCH are logical RDF operations with enhanced semantics and behaviour:
    • LDP servers must interpret relative URIs as relative to the resource (for example, allowing null relative URIs "<>" to refer to the to-be-created resource URI)
    • LDP Servers may adopt standards such as SPARQL/Update for update semantics via methods such as PATCH
    • LDP Servers must provide, at minimum, text/turtle and application/ld+json representations when requested via GET.

At present, the mapping of Fedora concepts to LDP Concepts are as follows

LDP ConceptFedora ConceptLDP Interaction ModesConstraints on Content
LDPCObjectLDPC, LDP-RSRDF, must contain LDP membership triples, subjects must be repository objects, subjects must be the URI of the object
LDP-NRDatastreamLDPR for properties, LDP-NR for bitstreamnone
LDP-RS-NC---

The issue at hand is whether Fedora should support the LDP construct of an RDF source that is not also a container (LDP-RS-NC), and how such an resource in LDP would map to a concept in Fedora.

 

 

 

Proposal 1:  Fedora container object with a child resource at a specified path redirecting to external content

LDP to Fedora mapping

LDP ConceptFedora ConceptLDP Interaction ModesConstraints on Content
LDPCObjectLDPC, LDP-RSRDF, must contain LDP membership triples, subjects must be repository objects, subjects must be the URI of the object
LDP-NRDatastreamLDPR for properties, LDP-NR for bitstreamnone
LDP-RS-NC---

Note that this proposal maintains the current behaviour in that LDP-RS-NC is not supported.

Request 1:  create container object

curl -i -X PUT "http://localhost:8080/rest/my_external_datastream_obj"

HTTP/1.1 201 Created
ETag: "f93bbf77fee0fa16da4872102a54240e7135eaf2"
Last-Modified: Thu, 12 Mar 2015 20:56:08 GMT
Content-Length: 53
Location: http://localhost:8080/rest/my_external_datastream_obj
Content-Type: text/plain
Server: Jetty(8.1.12.v20130726)

curl -H "Accept: text/turtle" "http://localhost:8080/rest/my_external_datastream_obj"

<http://localhost:8080/rest/my_external_datastream_obj> a ldp:RDFSource , ldp:Container , <http://www.jcp.org/jcr/nt/1.0folder> , <http://www.jcp.org/jcr/nt/1.0hierarchyNode> , <http://www.jcp.org/jcr/nt/1.0base> , <http://www.jcp.org/jcr/mix/1.0created> , fedora:Container , fedora:Resource , fedora:Resource , <http://www.jcp.org/jcr/mix/1.0created> , <http://www.jcp.org/jcr/mix/1.0lastModified> , <http://www.jcp.org/jcr/mix/1.0referenceable> ;
        fedora:lastModifiedBy "bypassAdmin"^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:uuid "fe7a8497-d826-490d-a786-ba601e039055"^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:createdBy "bypassAdmin"^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:primaryType "nt:folder"^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:created "2015-03-12T20:56:08.468Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
        fedora:mixinTypes "fedora:Container"^^<http://www.w3.org/2001/XMLSchema#string> , "fedora:Resource"^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:lastModified "2015-03-12T20:56:08.468Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
        fedora:writable "true"^^<http://www.w3.org/2001/XMLSchema#boolean> ;
        fedora:hasParent <http://localhost:8080/rest/> ;
        fedora:exportsAs <http://localhost:8080/rest/my_external_datastream_obj/fcr:export?format=jcr/xml> .

<http://localhost:8080/rest/my_external_datastream_obj/fcr:export?format=jcr/xml> dc:format <http://fedora.info/definitions/v4/repository#jcr/xml> .

<http://fedora.info/definitions/v4/repository#jcr/xml> rdfs:label "jcr/xml"^^<http://www.w3.org/2001/XMLSchema#string> .

Request 2:  create child external content object

curl -i -X PUT -H"Content-Type: message/external-body; access-type=URL; URL=\"http://en.wikipedia.org/wiki/File:Harry_Whittier_Frees_-_What%27s_Delaying_My_Dinner.jpg\"" "http://localhost:8080/rest/my_external_datastream_obj/extds"

HTTP/1.1 201 Created
ETag: "cbc2d06dd76fe1b3f6379e5dc0b8212ab056443e"
Last-Modified: Thu, 12 Mar 2015 21:08:33 GMT
Link: <http://localhost:8080/rest/my_external_datastream_obj/extds/fcr:metadata>; rel="describedby"
Content-Length: 59
Location: http://localhost:8080/rest/my_external_datastream_obj/extds
Content-Type: text/plain
Server: Jetty(8.1.12.v20130726)

http://localhost:8080/rest/my_external_datastream_obj/extds

curl -i "http://localhost:8080/rest/my_external_datastream_obj/extds"

HTTP/1.1 307 Temporary Redirect
ETag: "cbc2d06dd76fe1b3f6379e5dc0b8212ab056443e"
Last-Modified: Thu, 12 Mar 2015 21:08:33 GMT
Content-Type: message/external-body; access-type=URL; url="http://en.wikipedia.org/wiki/File:Harry_Whittier_Frees_-_What%27s_Delaying_My_Dinner.jpg"
Content-Length: 0
Accept-Ranges: bytes
Content-Disposition: attachment; filename=""; creation-date="Thu, 12 Mar 2015 21:08:33 GMT"; modification-date="Thu, 12 Mar 2015 21:08:33 GMT"; size=0
Link: <http://www.w3.org/ns/ldp#Resource>;rel="type"
Link: <http://www.w3.org/ns/ldp#NonRDFSource>;rel="type"
Link: <http://localhost:8080/rest/my_external_datastream_obj/extds/fcr:metadata>; rel="describedby"
Allow: DELETE,HEAD,GET,PUT,OPTIONS
Location: http://en.wikipedia.org/wiki/File:Harry_Whittier_Frees_-_What%27s_Delaying_My_Dinner.jpg
Server: Jetty(8.1.12.v20130726)

The complete thing

curl -H "Accept: text/turtle" -H "Prefer:  return=representation; include=\"http://fedora.info/definitions/v4/repository#EmbedResources\";" "http://localhost:8080/rest/my_external_datastream_obj"

<http://localhost:8080/rest/my_external_datastream_obj> a ldp:RDFSource , ldp:Container , <http://www.jcp.org/jcr/nt/1.0folder> , <http://www.jcp.org/jcr/nt/1.0hierarchyNode> , <http://www.jcp.org/jcr/nt/1.0base> , <http://www.jcp.org/jcr/mix/1.0created> , fedora:Container , fedora:Resource , fedora:Resource , <http://www.jcp.org/jcr/mix/1.0created> , <http://www.jcp.org/jcr/mix/1.0lastModified> , <http://www.jcp.org/jcr/mix/1.0referenceable> ;
        fedora:lastModifiedBy "bypassAdmin"^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:uuid "fe7a8497-d826-490d-a786-ba601e039055"^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:createdBy "bypassAdmin"^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:primaryType "nt:folder"^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:created "2015-03-12T20:56:08.468Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
        fedora:mixinTypes "fedora:Container"^^<http://www.w3.org/2001/XMLSchema#string> , "fedora:Resource"^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:lastModified "2015-03-12T21:08:33.787Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
        fedora:writable "true"^^<http://www.w3.org/2001/XMLSchema#boolean> ;
        fedora:hasParent <http://localhost:8080/rest/> ;
        ldp:contains <http://localhost:8080/rest/my_external_datastream_obj/extds> .

<http://localhost:8080/rest/my_external_datastream_obj/extds> a <http://www.jcp.org/jcr/nt/1.0resource> , <http://www.jcp.org/jcr/nt/1.0base> , <http://www.jcp.org/jcr/mix/1.0mimeType> , <http://www.jcp.org/jcr/mix/1.0lastModified> , fedora:Binary , fedora:Resource , <http://www.jcp.org/jcr/mix/1.0created> , <http://www.jcp.org/jcr/mix/1.0lastModified> , <http://www.jcp.org/jcr/mix/1.0referenceable> ;
        fedora:lastModifiedBy "bypassAdmin"^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:uuid "86aa4107-768d-4e2d-9064-78be072c0888"^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:mimeType "message/external-body; access-type=URL; url=\"http://en.wikipedia.org/wiki/File:Harry_Whittier_Frees_-_What%27s_Delaying_My_Dinner.jpg\""^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:digest <urn:sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709> ;
        premis:hasSize "0"^^<http://www.w3.org/2001/XMLSchema#long> ;
        fedora:createdBy "bypassAdmin"^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:primaryType "nt:resource"^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:created "2015-03-12T21:08:33.787Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
        fedora:mixinTypes "fedora:Binary"^^<http://www.w3.org/2001/XMLSchema#string> ;
        fedora:lastModified "2015-03-12T21:08:33.787Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
        premis:hasOriginalName ""^^<http://www.w3.org/2001/XMLSchema#string> .

<http://localhost:8080/rest/my_external_datastream_obj> fedora:exportsAs <http://localhost:8080/rest/my_external_datastream_obj/fcr:export?format=jcr/xml> .

<http://localhost:8080/rest/my_external_datastream_obj/fcr:export?format=jcr/xml> dc:format <http://fedora.info/definitions/v4/repository#jcr/xml> .

<http://fedora.info/definitions/v4/repository#jcr/xml> rdfs:label "jcr/xml"^^<http://www.w3.org/2001/XMLSchema#string> .

Proposal 2: LDP-RS as datastreams

In this proposal, an LDP-RS-NC maps to a Fedora datastream.  In the fedora object model, they are no different from the datastreams that already exist, and have no inherent characteristics that make them different in any way.  The difference lies in the HTTP API, in that they support the LDP-RS interaction mode as described in the background section of this document. 

An LDP-RS-NC (datastream) shall be created when the client specifies an LDPR interaction model for newly created resources as per section 5.2.3.4 of the LDP spec.

LDP to Fedora mapping

LDP ConceptFedora ConceptLDP Interaction ModesConstraints on Content
LDPCObjectLDPC, LDP-RSRDF, must contain LDP membership triples, subjects must be repository objects, subjects must be the URI of the object
LDP-NRDatastreamLDPR for properties, LDP-NR for bitstreamnone
LDP-RS-NCSpecial datastreamLDPR, LDP-RSRDF

Note that objects in the Fedora model map to the LDPC interaction model, while any resource that provides a datastream's properties and the new special type of datastream introduced here both map to the LDPR interaction model. The distinguishing factor of a Fedora object, as exposed by LDP, is that it is a container.  The distinguishing factor of a special datastream, exposed in LDP, is that it is not a container (i.e. it is a leaf node in the LDP model).

Discussion

Mapping the LDP-RS-NC (non-container RDF source resources) to datastreams has several consequences as a result of the LDP-RS interaction mode defined by LDP, or as a result of their nature as a datastream

  1. The Fedora object model does not change at all with this proposal
  2. The LDP-RS-NCs created by Fedora may contain arbitrary RDF.  This is a consequence of their 'datastream' nature, in that their content is largely opaque to the Fedora model.  They are blobs, so there is no inherent need to constrain their content other than to verify that they contain RDF as implied by an LDP-RS.
    1. No inherent restriction on allowable subjects, predicates, or objects in the triples
    2. No inherent restriction on constructs such as blank nodes
    3. This implies an unknown but high cost for implementation.
  3. The LDP-RS-NCs created to by Fedora may be 'pure' in that they are logically unmodified from client requests.  Again, this is due to their nature as an opaque datastream as far as the fedora model is concerned.  
    1. No server managed triples are added by Fedora
  4. The LDP-RS-NCs benefit from the LDP-RS interaction model as defined by LDP on these resources:
    1. Retrieve triples in specified representation (xml, turtle, ntriples, etc); as per LDP spec text/turtle and application/ld+json representations are always available.
    2. SPARQL Update semantics (PATCH)
    3. Interpretation of relative URIs in RDF content as per the LDP spec (for example, allowing null relative URIs "<>" to refer to the to-be-created resource URI)
    4. This also implies an unknown but high cost for implementation.

If it helps, this proposal can be also be conceptualized as a kind of 'service' provided on top of a datastream to provide an enhanced RDF CRUD API that neatly maps to an LDP concept that Fedora does not currently support, but most LDP servers do.  

Use cases

  • Arbitrary RDF documents as 'assets' managed by Fedora, yet accessible via the LDP-RS API.  For example, Tim Berners-Lee's FOAF file.
    • It contains multiple subjects, for example when providing details of linked blog posts, papers, or conferences.
  • Named-graph provenance
  • A place to put statements that are not allowable in Fedora objects, as a pragmatic workaround (e.g. assertions about an external resource)

Implementation notes

  1. Fedora may describe these resources using slightly different metadata in their corresponding 'fcr:metadata' resources.
    1. For example, "fedora:mixinTypes "fedora:NonRdfSourceDescription"^^<http://www.w3.org/2001/XMLSchema#string>" is probably not appropriate.
  2. Basic validation as well-formed RDF or SPARQL/update statements is a prerequisite for accepting content.
  3. The binary representation of an LDP-RS-NC as persisted in Fedora as datastream content may potentially be opaque (a decision would need to be made on this)
    1. The serialization format may be specified in advance.  For example, Fedora may chose to serialize as turtle, always
    2. Fedora may perhaps chose to store the exact binary content supplied by the client via PUT, and record metadata indicating which RDF serialization had been persisted.
    3. Likewise, the content may be entirely opaque, leaving it an implementation decision that can change at any time.

Proposal 3:  LDPRs as "Pointlike objects"

In this view, LDP-RS-NCs appear in the repository as objects without datastreams or contained objects. They would possess all the functions of other objects, except that attempts to add children to them (datastreams or child objects) would fail under all circumstances. They could support the interaction described in section 5.2.3.4 of the LDP specification, if a client so specifies in the appropriate way when creating one. Their serializations would be no different from those of any other object, nor would they offer a special binary representation of any kind, other than as provided for by any object in the repository.

LDP to Fedora mapping

LDP ConceptFedora ConceptLDP Interaction ModesConstraints on Content
LDPCObjectLDPC, LDP-RSRDF, must contain LDP membership triples, subjects must be repository objects, subjects must be the URI of the object
LDP-NRDatastreamLDPR for properties, LDP-NR for bitstreamnone
LDP-RS-NCObjectLDPR, LDP-RSRDF, subjects must be repository objects, subjects must be the URI of the object

Note that objects in the Fedora model map to the LDP-RS interaction model, while datastreams in Fedora map to the LDPR and LDP-NR interaction models.

Proposal 4: LDPRs as "Pointlike objects" with no constraints on RDF statements.

(This is included largely for completeness sake, but it is very interesting)

This is like the "LDPRs as pointlike objects" proposal, except that it removes Fedora's existing constraints on triples associated with objects in general.  In this view, an LDP-RS can be seen as a bag of triples with an identity (named graph).  Fedora enhances the value of these resources by defining an ontology, and maintaining a set of triples that express its identity in the Fedora object model according to this ontology.  This bestows LDP-RS resources with the identity and structure of Fedora objects.  Triples within an LDP-RS that are not part of the Fedora model, and violate Fedora's assumptions (such as "subjects must be the URI of the resource") are preserved as part of the resource and named by its URI, but may be ignored by services that are build on top of the Fedora object model.  Users of Fedora can embrace or extend the Fedora model, or ignore it completely.  

LDP ConceptFedora ConceptLDP Interaction ModesConstraints on Content
LDPCObjectLDPC, LDP-RSRDF, must contain LDP membership triples
LDP-NRDatastreamLDPR for properties, LDP-NR for bitstreamnone
LDP-RS-NCObjectLDPR, LDP-RSRDF

Note that 'Objects' in the Fedora model map to the LDP-RS interaction model, while 'Datastreams' in Fedora map to the LDP-NR interaction model.  The distinguishing factor of a Fedora object, as exposed by LDP, is that is an RDF source.   The distinguishing factor of the resource that provides a datastream's bitstream is that it is a non-RDF source.

Discussion

In this proposal, Fedora's relationship with LDP can be seen as a "value add service:" in creating an LDP-RS, Fedora enhances the value of these LDP resources by managing a set of triples that give it an identity in the Fedora model, describe it as such, and enable services on it such as fixity, indexing, etc.  

  • Any statements outside this ontology are preserved, but largely ignored by the Fedora service stack (except, perhaps general-purpose services such as triple store indexing).  
  • To an outside user, Fedora would appear just like a fully-featured LDP service that happens to have a lot of server-managed triples.  
    • Fedora would be completely usable as a generic LDP service without any knowledge of the Fedora model
    • An outside user would not need to understand the Fedora model in order to understand why an LDP request failed.
  • To a current user of Fedora 4, there would be no observable difference in an object and how it behaves, other than the fact that triples will not be rejected unless they contradict the Fedora ontology

Use cases

  • Allow Fedora to be used with models that make use of assertions about non-repository objects (e.g. Hydra use case,  Tom Johnson?)
  • Allow Fedora to coexist with models that are unrelated to the Fedora ontology
  • Decouple Fedora from LDP
    • Fedora could be thought of as a model and set of services that exists on top of LDP, rather than as part of it.
  • Named graphs for provenance would be a bit of a challenge unless there were a way to distinctly separate triples from the Fedora ontology/model from those provided by the user
    • This is where the mailing list suggestion of "a way to exclude server managed triples" when GETting RDF from an object may be relevant, if support of that use case natively is a goal.

Implementation notes

  • According to JIRA and the mailing list, this would be difficult to implement, given the way Fedora objects are currently expressed as JCR nodes
    • I believe triples are currently expressed as properties in the JCR model.  Do Fedora objects (not datastreams) have any JCR binary content?  If not, could that be leveraged to implement something like this (e.g. serialize all statements that do not have a repository subject as binary)

 

  • No labels

28 Comments

  1. A. Soroka, from the email thread, you advocate for removing the following points from Aaron Birkland's proposal:

    1. Allow the LDP-RS-NCs created by Fedora to contain arbitrary RDF
      1. No requirements on allowable subjects, predicates, or objects in the triples
      2. No constraints on constructs such as blank nodes
    2. Allow the LDP-RS-NCs created to by Fedora to be 'pure' in that they are logically unmodified from client requests
      1. No server managed triples are added by Fedora

    I agree with excluding 1.a (2.a from the wiki text), but why do you suggest not supporting blank nodes?

    As for 2.a (3.a from the wiki text), I thought there was consensus moving towards making "server-managed" triples configurable, no?

    1. In fact I was imprecise in my remark on the email thread-- for point 2.a (wiki text), I am completely opposed, but point 2.b I find completely orthogonal to the rest of the proposal and I think it muddies the waters to even be discussing it in this context.

      As for 3.a, yes, that's what I felt too. Again, it's (as I said in the email thread) unrelated to the heart of the matter here (non-LDPC LDPRs) and I don't see why we're even talking about it in the same discussion.

      In short, I think Aaron packed a bit too much in here, and I'd like to break it back out again so that we can discuss each of his requests with the attention they each deserve.

       

    2. Please don't!  It is essential to understanding what the proposal is and does, and is a key differentiating factor.   If anything, maybe change "addresses the following issues" to "has the following features?"

      1. Breaking the concepts out or not, can we discuss the line-items in-turn? It appears that whether the points are packed into an omnibus proposal or more granular, separate proposals, we would benefit from finding the points where we currently agree, and where we need to find a compromise.

        1. I'm fine with that. Aaron Birkland, please understand that point 2.a is a complete blocker for me. I will certainly veto that, given the chance. I really think it's in the interest of full discussion and, as Andrew Woods says, compromise, to be able to discuss at least it independently.

        2. Hi Andrew,

          I'll reorganize so that it's clear that the proposal is simple:  "Non-container LDP-RS correspond to datastreams in the Fedora model".  The rest are consequences that naturally fall out from that  (i.e. based on what the LDP API does, and on what datastreams are).  For example, 2.a "No requirements on allowable subjects..." would be a consequence of being a datastream, while 4.c "SPARQL/Update" is a consequence of the LDP API and the kind of operations it allows on LDP-RS.

          1. +1. I think this way of thinking about the two proposals gets closer to the heart of the matter. This is why I've been badgering us to answer the question of how these things fit into the Fedora model.

            1. At a first glance, I'm also +1 on this.

              I'm also +1 on clarifying the relationship between LDP and Fedora's model, generally.

  2.  

    • The Fedora object model does not change at all with this proposal

     

    I think this claim bizarre. Clearly, the entire purpose of the proposal from which I'm quoting it is to create a new special kind of datastream that, unlike every previous type of datastream in Fedora history, is transparent to the repository and offers special services because of its media-type. This is clearly a serious change in the Fedora object model.

    1. It is a datastream that has a particular enhanced API above it, one that is defined by the LDP standard. LDP offers special services on resources precisely because of their media type, hence the LDP-RS interaction mode discussed in the intro.  So this proposal is merely "it would be very useful to allow this API on top of Fedora datastreams that the user wants to expose with the RDF-RS interaction model"

      1. Right. The creation of a type of "datastream that has a particular enhanced API" is certainly a serious change in the model. That's my point. I'm not saying we can't do this-- I'm saying that it's confusing to suggest that we're not changing the model.

        One question raised by this characterization (the idea of an "bonus" API over certain special datastreams) is whether this kind of functionality belongs in an add-on module. We've talked before about the ability Fedora now has to store arbitrary RDF opaquely in datastreams, and you described that as unacceptable because the LDP interaction models seem so convenient to you. Perhaps offering the LDP interaction models over special parts of the repository is a good job for some kind of additional service akin to the current transformation service.

        There are other conversations in the community about the direction in which the CMA idea of dissemination should evolve, and one part of that conversation has been some considerable agreement that we need to provide "bidirectional" forms for dissemination. It seems to me that additional forms of interaction model over special datastreams fits nicely into that structure.

        1.    It's not a 'bonus' API as far as LDP is concerned.  In fact, because Fedora has chosen to adopt LDP as its API the question is relevant in the scope of "LDP to Fedora object mapping", rather than "external services".  From the perspective of LDP, mapping to a datastream it makes sense, is useful, is analogous to a construct mentioned in the standard, and does not introduce any strange or confusing behaviour, so that's why I think it is worth considering.

          If anything, deciding to do anything with LDP-RS-NCs is "seriously changing the model" as far as I understand your perspective.  So maybe it's best not to?

          1. Fedora did not adopt LDP as its API. We chose to make the Fedora API compliant with LDP. There's a world of difference. In the first case, we have a responsibility to provide the functionality that LDP provides. In the second, we have a responsibility to provide whatever functionality Fedora provides in a way that is compatible with LDP.

            It's disingenuous to suggest that I am entirely opposed to changing the Fedora model. I am opposed to changing it for no other reason than that you (or anyone else) would find certain new functionality convenient. What's more, you will note that I have offered on this very page a way of providing for LDP-RS-NCs without changing the model at all. I understand that you may not find that option attractive, but I can only suggest again that refusing to separate the issue of support for LDP-RS-NCs from the issue of support for arbitrary RDF is not going to help us come to any useful course of action.

            1. I guess I just don't understand how the act mapping of an LDP construct to a Fedora construct is changing the Fedora object model at all, regardless of proposal.  'Adopt' vs 'compliant with' is synonomous as far as I am concerned:  both to me imply that the important fact that Fedora has chosen to do a mapping between LDP concepts and Fedora concepts in the first place, hence why the choice of "which fedora concept does an LDP-RS-NC map to" is a question to consider.  I really haven't seen an argument as to why "LDP-RS-NC" as a pointlike object (3) ought to exist at all - there is no discussion, no use cases, or anything in the wiki proposal!  Why is the datastream proposal guilty until proven innocent?   Is not utility/usefuness a relevant factor to consider?

              The 'datastream' proposal may or may not end up not being the best for the community, but I think there is room to argue either way about which proposal modifies or does not modify the object model, how severely, and whether is is worth it.  There is also room to consider whether usefulness of the proposal (in terms of use cases that are enabled/disallowe) weighs in.

              1. Aaron, I'll try and answer your questions here, but some of my answers are just going to repeat things I've already said, because in some cases I don't see how I could be much clearer.

                There certainly is a difference between 'adopt' and 'compliant with', and I explained it above. Fedora is not solely an LDP implementation and the fact that it does implement LDP does not mean that it must implement all of LDP. The specification is very clear in its use of MUST, SHOULD, etc., and in particular the question of whether or not LDP-RS-NCs should be create-able is explicitly left as an implementation decision.

                No one, to my knowledge, is arguing about whether the choice of '"which fedora concept does an LDP-RS-NC map to" is a question to consider', so I don't know what to tell you there, Aaron. That's exactly what this whole wiki-page-conversation is about. The fact that I don't agree with your suggestion for that mapping (or the fact that you refuse to disentangle it from your other suggestions) doesn't mean that we're not still talking.

                As for the question of utility, it's certainly relevant. It's not, however, the only concern. If the only question we ask when we decide whether to add new functionality to Fedora is, "Will anyone find this useful?" we would add a lot of out-of-scope and unmaintainable functionality. You know as well as do I that we ask many other questions, the most important of which in this discussion is "Is this is actually in-scope for the kind of tool Fedora is?"

                And lastly, the purpose of the "pointlike object" proposal is simple: it allows us to offer LDP-RS-NCs without introducing magic transparent datastreams, but instead simply by restricting a construct that is already present in the system. This seems to me far more natural and appropriate, and what's more it meets, to my eye, all the use cases that have been put forward by Benjamin ArmintorNeil Jefferies and Scott Prater. It does not meet yours, but I submit that that is because you refuse to disentangle your desire to store arbitrary RDF in an object repository from your desire to avoid system-managed triples from your desire to have LDP-RS-NCs available as constructs.

  3. Use cases

    • Arbitrary RDF documents as 'assets' managed by Fedora, yet accessible via the LDP-RS API.  For example, Tim Berners-Lee's FOAF file.
      • It contains multiple subjects, for example when providing details of linked blog posts, papers, or conferences.
    • Named-graph provenance
    • A place to put statements that are not allowable in Fedora objects, as a pragmatic workaround (e.g. assertions about an external resource)

    In what way are any of these things use cases for an object repository? They all sound very much like jobs for a good triple store.

    1. This point was mentioned on the list, but I think it bears repeating as it is very important:  Fedora has a strong use case for preserving digital assets (images, audio recordings, RDF documents etc), with the object model as a means to an end.   So storing an asset as a datastream is meaningful, intentional, and has particular value.  Allowing access to RDF assets via a well-defined API, such is spelled out in LDP as an LDP-RS, is extremely useful.  This proposal gives us both.  A triple store is not a repository, and fedora is really good at managing digital assets that are not objects.

       

      I see a triplestore as a special kind of index, not as any kind of
      technology suitable for archival storage, nor equivalent to a
      repository.

      With these kind of resources in Fedora, here's what I get:

      • Exposure of a named graph as a resolvable HTTP resource
      • Standards-based CRUD on these named graph resources as RDF
      • The ability to store them as a unit/document/file/blob in a JCR repository
      • A good API for creating them via LDP
      • A nice way to allow services to consume them as a unit via messaging/camel
      • A means of access control
      • Some useful system metadata from Fedora.
      • Versioning
      • Transactions
      • etc


      To me, that is a lot of value - and one of the reasons I was eager to
      evaluate Fedora 4 for this potential use case.

      1. I think this is a place where we'll have to agree to disagree for the moment, because we're speaking from two very different points of view. You're telling me about utility, and I'm telling you about scope. The fact that a plausible new functionality seems very useful to you doesn't convince me that we should spend the time and effort to implement it, and the fact that the same new functionality seems to me to be wildly out of scope doesn't convince you that we should fail to give Fedora adopters the advantage it provides.

        1. I think in terms of utility because I'm trying figure out how we can use Fedora 4, identifying the stumbling blocks could preventing us from doing so, and helping to contribute to a conversation which I hope will consider the practical needs of the users of Fedora (I am just one).  I hope other people are interested enough to weigh in as well, consensus does not lie with one person.   Indeed, maybe coming to a decision right now is a bit premature, and the solution is "we will disallow LDP-RS-NCs until more people argue that we need that kind of resource, and a consensus has been reached as to how it maps to the Fedora model).

          1. I appreciate very much the contribution you're making by taking the time to have this discussion. One facet of it that does concern me is the extent to which it has been dominated by our voices. But as far as I am concerned, we have heard from other people (I'm thinking here particularly of Benjamin Armintor and Neil Jefferies) who are interested in using these kinds of constructs and we are in the phase of getting consensus on how it maps to the Fedora model.

            1. Yes, also Scott Prater and Tom Johnson.  I'm not going to be able to attend the phone meeting, but I do hope that a decision isn't made until the committers feel that everybody interested in the subject has had a chance to weigh in, and their feedback is accurately reflected in the proposals being considered

  4. To a current user of Fedora 4, there would be no observable difference in an object and how it behaves, other than the fact that triples will not be rejected unless they contradict the Fedora ontology

    This seems like a profoundly dangerous statement to me. OWL and its ilk are not intended to be used for and are not useful for validation.

    1. Can you elaborate as to the danger?  How is OWL related to this?  Are Fedora's constraints enforced by OWL?   Maybe the phrase "unless they contradict the Fedora ontology" Should be replaced by "unless they contradict <whatever constraints Fedora places on its model, however way does it>"

      1. OWL is the richest practical means by which we can express some ontology in a machine-actionable way, and the current Fedora ontology is written in OWL, so I assumed that that was what you meant.

        Fedora's constraints are not enforced by OWL because no constraints anywhere are enforced by OWL because OWL is not a language that can be used for that purpose (unless you're talking about something like Clark & Parsia's ICV, which I don't think you are). The other phrasing you suggest is certainly better. It might be even simpler to just say, "subject to the constraints of the Fedora model". I don't understand the specifics of how that happens to be of interest for your point.

  5. +1 to Option 3.
     

    Also please note that Fedora4 already supports the creation of datastreams that happen to be RDF by setting Content-Disposition: attachment on the request. (hat tip to Chris Beer)  This is outside of LDP, which doesn't have a means to do this at all.

  6. Options 3 and 4 make the most sense to me, and not doing 3 minimally seems like a design flaw to me. 

    The LDP spec describes an implicit inheritance between the interaction models: LPDC is a subtype of LDPRS, which is a subtype of LDPR.

    If we understand a Datastream to be LDPNR, then adding an LDPRS interaction model to it is going to be contra the behaviors expected of Datastreams (what does a RDF PATCH mean to a fixity-checked binary?), and against the LDP spec, The LDP spec has LDPRS and LDPNR as two disjoint classes of behavior, both of which "must also be a conforming LDP Resource (LDPR)".

    1. Just to be clear, Benjamin Armintor, when you say "Options 3 and 4 make the most sense to me, and not doing 3 minimally seems like a design flaw to me." you mean "Let's at least do 3 and preferably do 4.", right?

      1. I don't know if I prefer 4, but yes: Lack of support for #3 LDPRSs seems like a bug to me.