Re: [fedora-tech] Static LDP

Unfortunately the the ldp-testsuite [1] has not been active recently, nor
responsive to recent pull requests:
https://github.com/w3c/ldp-testsuite/pulls

In communication with the LDP Next effort (cc'd here), maybe it is time to
move forward with a fork of the ldp-testsuite.

Regards,
Andrew
[1] https://github.com/w3c/ldp-testsuite


On Tue, Apr 11, 2017 at 11:04 AM, Aaron Coburn <acoburn@amherst.edu> wrote:

> Andrew,
> For the reasons Jared has already mentioned, I have not bothered with the
> LDP test suite -- it is flawed in a number of ways, and for most things, it
> is irrelevant (e.g. PATCH to an IndirectContainer). Instead, I have relied
> on a close reading of the spec itself.
>
>
> > On Apr 11, 2017, at 10:56 AM, Jared Whiklo <jwhiklo@gmail.com> wrote:
> >
> > Hi Andrew,
> >
> > I actually wondered about this tried it out a little bit, but the test
> > suite is seemingly flawed.
> >
> > A test of a directory (therefore a BasicContainer) reports errors such as
> >
> >> [FAILURE] BasicContainerTest.testGetResourceAcceptTurtle
> >>
> >> LDP servers must respond with a Turtle representation of the
> >> requested LDP-RS when the request includes an Accept header
> >> specifying text/turtle, unless HTTP content negotiation requires a
> >> different outcome [turtle].
> >>
> >> java.lang.IllegalArgumentException: Unsupported media type:
> > text/turtle; charset=UTF-8
> >
> > Because the test can't handle the charset? Not sure.
> >
> > Or
> >
> >> [FAILURE] BasicContainerTest.testLdpLinkHeader
> >>
> >> LDP servers exposing LDPRs MUST advertise their LDP support by exposing
> a HTTP
> >> Link header with a target URI of http://www.w3.org/ns/ldp#Resource,
> and a link
> >> relation type of type (that is, rel='type') in all responses to
> requests made
> >> to the LDPR's HTTP Request-URI.
> >>
> >> java.lang.AssertionError: 4.2.1.4 LDP servers exposing LDPRs must
> advertise their LDP support by exposing a HTTP Link header with a target
> URI of http://www.w3.org/ns/ldp#Resource, and a link relation type of
> type (that is, rel='type') in all responses to requests made to the LDPR's
> HTTP Request-URI. Actual: null expected [true] but found [false]
> >
> > But the headers returned were
> >
> > HTTP/1.1 200 OK
> > Date: Tue, 11 Apr 2017 14:49:27 GMT
> > Server: Apache/2.4.25 (Unix) PHP/5.6.29 PHP/7.1.3
> > X-Powered-By: PHP/7.1.3
> > Cache-Control: private, must-revalidate
> > Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
> > Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"
> > Vary: Accept
> > Last-Modified: Sat, 01 Apr 2017 04:49:13 GMT
> > ETag: "3de0abdde505df10435ed3f4e0d66cfe8a1bdc02"
> > Content-Length: 459
> > Content-Type: text/turtle; charset=UTF-8
> >
> > So I'm not sure using that test suite does much to validate the LDPness
> > of a server.
> >
> > cheers,
> > jared
> >
> >
> >
> > On 2017-04-11 8:45 AM, Andrew Woods wrote:
> >> Thanks for putting Static-LDP out to the community, Aaron.
> >>
> >> It is exactly this kind of innovation that we are hoping to see come
> >> from the Fedora API Specification effort. Once we have the first public
> >> working draft of the specification and the supporting test compatibility
> >> suite, it will make it much more clear for the community to determine
> >> the characteristics of a given Fedora implementation.
> >>
> >> In the meantime, have you had a chance to run the LDP test suite against
> >> Static-LDP?
> >> https://dvcs.w3.org/hg/ldpwg/raw-file/default/tests/reports/ldp.html
> >>
> >> Nice work.
> >> Andrew
> >>
> >> On Tue, Apr 11, 2017 at 9:09 AM, Esmé Cowles <escowles@ticklefish.org
> >> <mailto:escowles@ticklefish.org>> wrote:
> >>
> >>    Aaron-
> >>
> >>    This looks great — I'm looking forward to spinning this up and
> >>    seeing if we can use it instead of vanilla nginx for serving our
> >>    binaries.
> >>
> >>    -Esmé
> >>
> >>> On Apr 11, 2017, at 8:59 AM, Aaron Coburn <acoburn@amherst.edu
> >>    <mailto:acoburn@amherst.edu>> wrote:
> >>>
> >>> Hi, Folks,
> >>>
> >>> I'd like to announce the initial release of "Static-LDP", a
> >>    conforming linked data server that sits atop static, user-managed
> >>    resources.
> >>>
> >>> There has been a lot of discussion on this and other lists about
> >>    "external content" and Fedora's support for user-managed content via
> >>    the `external-body` redirect mechanism. At Amherst, we also have the
> >>    need to manage external content and link to it from Fedora (e.g.
> >>    large video files), but as many of you know, I have never been a fan
> >>    of the `external-body` redirect mechanism: it conflates
> >>    Fedora-managed resources with user-managed resources in a way that I
> >>    don't like and would never encourage. So this is my opening salvo
> >>    for an alternative.
> >>>
> >>> As Francis Bacon wrote in the 1600s:
> >>>
> >>>      Mahomet cald the Hill to come to him. And when the Hill
> >>    stood still, he was neuer a whit abashed, but said; If the Hill will
> >>    not come to Mahomet, Mahomet wil go to the hil.
> >>>
> >>>
> >>> The basic idea behind StaticLDP is that a repository
> >>    infrastructure may contain a mix of repository-managed and
> >>    user-managed resources. And sometimes it is not feasible (or highly
> >>    inconvenient) to bring all of those resources into a
> >>    repository-managed system. On the other hand, leaving them entirely
> >>    external undermines much of the benefits of LDP.
> >>>
> >>> The other idea behind StaticLDP is that it is extremely simple.
> >>    Simple to install, simple to run, simple to maintain.
> >>>
> >>> Installation instructions contain two simple steps and are
> >>    described on the project github repository:
> >>    https://github.com/trellis-ldp/static-ldp
> >>    <https://github.com/trellis-ldp/static-ldp>
> >>>
> >>>
> >>> What does StaticLDP do?
> >>>
> >>> Given a directory of static assets, StaticLDP exposes them as LDP
> >>    resources: directories are ldp:BasicContainers (LDP-C), RDF
> >>    documents are ldp:RDFSources (LDP-RS) and everything else is a
> >>    ldp:NonRDFSource (LDP-NR).
> >>>
> >>> an LDP-RS can be any valid RDF; there are no constraints on this:
> >>    blank nodes, out-of-domain subjects, anything goes. These resources
> >>    respond to content negotiation (you store a file as Turtle, but
> >>    retrieve it as JSON-LD). If you request an LDP-RS in the format in
> >>    which it is serialized, the file is streamed directly to the client
> >>    -- no parsing or serialization is involved. If any
> >>    parsing/serialization _is_ performed, relative IRIs are resolved
> >>    relative to the requested URL. LDP-RSs can describe LDP-NRs: given
> >>    an LDP-NR (/foo.jpg), the corresponding rel="describes" and
> >>    rel="describedby" Link headers will be automatically added if there
> >>    is a /foo.jpg.ttl (or any valid serialization such as
> >>    /foo.jpg.jsonld) file present. Also, ETags are all strong.
> >>>
> >>> an LDP-NR is simply a file, and it is streamed directly to a
> >>    client: file size can be arbitrarily large.
> >>>
> >>> an LDP-C (BasicContainer) contains a minimal set of triples:
> >>    ldp:contains for all of the resources in the directory, and a
> >>    dc:modified corresponding to the modification date of the directory.
> >>>
> >>> All resources can respond with instance digests in order to ensure
> >>    end-to-end data integrity: md5 and sha1 are supported. Clients would
> >>    use the `Want-Digest` header to generate this. All resources support
> >>    this, both LDP-NR and LDP-RS. The only exception is that a digest
> >>    will not be computed on range requests.
> >>>
> >>>
> >>> What does StaticLDP not do?
> >>>
> >>> StaticLDP is read-only. Any mutating HTTP operation will result in
> >>    a 405 Method not allowed exception. As per the LDP specification, a
> >>    ldp:constrainedBy Link header will be returned, pointing to
> >>    http://acdc.amherst.edu/ns/trellis#ReadOnlyResource
> >>    <http://acdc.amherst.edu/ns/trellis#ReadOnlyResource>.
> >>>
> >>> There are no plans to support write operations; being a read-only
> >>    LDP server means the code base is extremely small and simple (the
> >>    initial implementation was written in 30 minutes), and there is a
> >>    role for this type of a server in a larger repository ecosystem.
> >>>
> >>>
> >>> I would especially like to thank a lot of people who contributed
> >>    code and ideas for this project. I'd especially like to thank Jared
> >>    Whiklo (University of Manitoba) for rewriting much of my initial
> >>    attempt in a modern PHP style. Jared also wrote the entire testing
> >>    structure. And much of the initial idea for this came from a
> >>    conversation with A. Soroka and Jared Whiklo about ten days ago. I'd
> >>    also like to thank Diego Pino, Nick Ruest and Danny Lamb for their
> >>    ideas, code contributions and general support.
> >>>
> >>>
> >>> Oh and by the way, StaticLDP is a fully conforming Fedora server, too.
> >>>
> >>>
> >>> Regards,
> >>> Aaron Coburn
> >>>
> >>>
> >>> --
> >>> 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
> >>    <mailto:fedora-tech%2Bunsubscribe@googlegroups.com>.
> >>> To post to this group, send email to fedora-tech@googlegroups.com
> >>    <mailto:fedora-tech@googlegroups.com>.
> >>> Visit this group at https://groups.google.com/group/fedora-tech
> >>    <https://groups.google.com/group/fedora-tech>.
> >>> For more options, visit https://groups.google.com/d/optout
> >>    <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
> >>    <mailto:fedora-tech%2Bunsubscribe@googlegroups.com>.
> >>    To post to this group, send email to fedora-tech@googlegroups.com
> >>    <mailto:fedora-tech@googlegroups.com>.
> >>    Visit this group at https://groups.google.com/group/fedora-tech
> >>    <https://groups.google.com/group/fedora-tech>.
> >>    For more options, visit https://groups.google.com/d/optout
> >>    <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
> >> <mailto:fedora-tech+unsubscribe@googlegroups.com>.
> >> To post to this group, send email to fedora-tech@googlegroups.com
> >> <mailto:fedora-tech@googlegroups.com>.
> >> Visit this group at https://groups.google.com/group/fedora-tech.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > Jared Whiklo
> > jwhiklo@gmail.com
> > --------------------------------------------------
> > There is always one more imbecile than you counted on.
> >
> > --
> > 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 fedora-tech@googlegroups.com.
> > Visit this group at https://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 fedora-tech@googlegroups.com.
> Visit this group at https://groups.google.com/group/fedora-tech.
> For more options, visit https://groups.google.com/d/optout.
>