Re: [fedora-tech] Static LDP

Hi Andrew,

I've just invited @awoods to w3c/ldp-testsuite, so you can help on keeping
the test suite up-to-date.

I guess this would need a broader discussion from the CG Chairs how the
plan to move forward from what LDP 1.0 was to what you want to achieve with
LDPNext.

Cheers,

On Wed, Apr 12, 2017 at 3:39 PM, Andrew Woods <awoods@duraspace.org> wrote:

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