Re: [fedora-tech] Static LDP

Hello Sergio,
Thanks for the message and for being open to the LDP 1.0 Test Suite moving
forward. LDPNext and surrounding efforts are very important and I would be
happy to help by being a maintainer of the test suite. Just let me know of
any process details.

Regards,
Andrew

On Wed, Apr 12, 2017 at 2:39 AM, Sergio Fernández <wikier@apache.org> wrote:

> Hi Andrew,
>
> as one of the original developers of the LDP 1.0 Test Suite, I'm happy to
> handover its maintenance to someone who is still actively working on
> LDPNext.
>
> I can see Andrei has been handling couple of PRs yesterday:
> https://github.com/w3c/ldp-testsuite/pulls?q=is%3Apr+is%3Aclosed
>
> Cheers,
>
>
> On Tue, Apr 11, 2017 at 5:14 PM, Andrew Woods <awoods@duraspace.org>
> wrote:
>
>> 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.
>>>
>>
>>
>