A

Arrange for the resolver to poll each source for each of the synonym URIs.

Has Broader
Make the source tree into a "source".
Other
Some of the files in the source tree are UUIDs and some of them are ordinary path slugs. How do we target them?

B

The base class, RDF::SAK::Context, handles config, generated index resources, and target-specific metadata (e.g. rewrite maps).

Has Broader
RDF::SAK is sclerotic and too tightly-coupled to its proximate function as a static website generator.

C

Create the file system target as a sink. Have it "request" all of the resources and their variants.

Has Broader
Model the intervention of RDF::SAK to take representations from a source to a sink.
Other
How do we handle the existing file system target?
How is the static file system sink going to "know" what resources there are to "request"?

E

Eliminate "util" module(s) by rolling their functionality into static methods in related domain-specific modules.

Other
There is a gigantic "utility" module, RDF::SAK::Util(::Messy), that performs a number of sundry operations.

H

How do we handle the existing file system target?

Other
Create the file system target as a sink. Have it "request" all of the resources and their variants.
Model the intervention of RDF::SAK to take representations from a source to a sink.

How is the static file system sink going to "know" what resources there are to "request"?

Other
Create the file system target as a sink. Have it "request" all of the resources and their variants.
The sink should have access to the graph, or otherwise some kind of manifest of all the available resources.

I

Implement the Web application as another "sink".

Other
What about running RDF::SAK as a dynamic Web application?

In addition to the subject URL(s) then, the source will need access to Accept-* headers.

Other
Make the individual sources manage their own content negotiation.

M

Make the individual sources manage their own content negotiation.

Has Broader
Model the intervention of RDF::SAK to take representations from a source to a sink.
Other
In addition to the subject URL(s) then, the source will need access to Accept-* headers.
What about content negotiation?

Make the source tree into a "source".

Has Broader
Model the intervention of RDF::SAK to take representations from a source to a sink.
Has Narrower
Arrange for the resolver to poll each source for each of the synonym URIs.
Other
Some of the files in the source tree are UUIDs and some of them are ordinary path slugs. How do we target them?
What about the source tree on the file system?
What about version control?

Model the intervention of RDF::SAK to take representations from a source to a sink.

Has Narrower
Create the file system target as a sink. Have it "request" all of the resources and their variants.
Make the individual sources manage their own content negotiation.
Make the source tree into a "source".
Other
A unified interface for both source and sink would make either very easy to develop.
How do we handle the existing file system target?
RDF::SAK is sclerotic and too tightly-coupled to its proximate function as a static website generator.
Several operations need to happen to resource representations between the instant they are retrieved from the source to when they are delivered to the sink.
There is already a word in REST parlance for "source": "origin".
What about content negotiation?
What about running RDF::SAK as a dynamic Web application?
What about the source tree on the file system?

Model these operations as pure transformation functions.

Other
Several operations need to happen to resource representations between the instant they are retrieved from the source to when they are delivered to the sink.
These functions necessarily return a representation which can be memoized and keyed by its cryptographic hash.

N

Not every "source" is an "origin" (e.g. a gateway/reverse proxy).

Other
There is already a word in REST parlance for "source": "origin".

R

RDF::SAK is sclerotic and too tightly-coupled to its proximate function as a static website generator.

Has Narrower
The base class, RDF::SAK::Context, handles config, generated index resources, and target-specific metadata (e.g. rewrite maps).
There is a gigantic "utility" module, RDF::SAK::Util(::Messy), that performs a number of sundry operations.
Other
Model the intervention of RDF::SAK to take representations from a source to a sink.

S

Several operations need to happen to resource representations between the instant they are retrieved from the source to when they are delivered to the sink.

Other
Model the intervention of RDF::SAK to take representations from a source to a sink.
Model these operations as pure transformation functions.

Some of the files in the source tree are UUIDs and some of them are ordinary path slugs. How do we target them?

Other
Arrange for the resolver to poll each source for each of the synonym URIs.
Make the source tree into a "source".

The sink should have access to the graph, or otherwise some kind of manifest of all the available resources.

Other
How is the static file system sink going to "know" what resources there are to "request"?

T

There is a gigantic "utility" module, RDF::SAK::Util(::Messy), that performs a number of sundry operations.

Has Broader
RDF::SAK is sclerotic and too tightly-coupled to its proximate function as a static website generator.
Other
Eliminate "util" module(s) by rolling their functionality into static methods in related domain-specific modules.

There is a library interface to git, which could be used to create its own "source". A Mercurial interface will have to wrap the binary for all languages other than Python.

Other
What about version control?

There is already a word in REST parlance for "source": "origin".

Other
Model the intervention of RDF::SAK to take representations from a source to a sink.
Not every "source" is an "origin" (e.g. a gateway/reverse proxy).

These functions necessarily return a representation which can be memoized and keyed by its cryptographic hash.

Other
Model these operations as pure transformation functions.

U

A unified interface for both source and sink would make either very easy to develop.

Other
Model the intervention of RDF::SAK to take representations from a source to a sink.

W

What about content negotiation?

Other
Make the individual sources manage their own content negotiation.
Model the intervention of RDF::SAK to take representations from a source to a sink.

What about running RDF::SAK as a dynamic Web application?

Other
Implement the Web application as another "sink".
Model the intervention of RDF::SAK to take representations from a source to a sink.

What about the source tree on the file system?

Other
Make the source tree into a "source".
Model the intervention of RDF::SAK to take representations from a source to a sink.

What about version control?

Other
Make the source tree into a "source".
There is a library interface to git, which could be used to create its own "source". A Mercurial interface will have to wrap the binary for all languages other than Python.