Re: New I-D: Semantic Content Packages

On Mon, Apr 16, 2012 at 9:45 AM, Danny Ayers <danny.ayers@gmail.com> wrote:
> On 13 April 2012 19:48, Chris Wilper <cwilper@gmail.com> wrote:
>> Hello,
>>
>> I just posted a new Internet-Draft for "Semantic Content Packages",
>> now available at:
>> http://www.ietf.org/id/draft-wilper-semantic-content-pkgs-00.txt
>
> Interesting, sounds useful.

Thanks for having  a look.

> I was recently playing around with a variant of 'baking'  [1] in the
> sense of dumping material from a DB that's normally used to serve
> dynamically onto a filesystem for 'static' serving.

The "baking" term is new to me, but I very much agree with the
motivation -- freeing the the data from the particular store it was
originally created in; hopefully storing it more simply in order to
make keeping it around for a long time more reasonable a proposition.

> I've got graphs in
> a triplestore which can provide direct representations as Turtle etc.
> as well as HTML versions (essentially queries against the graphs
> pushed through templates). The graph naming will follow a typical path
> structure. So a baked version of http://example.org/users/fred would
> look something like:
>
> ./users/fred.html
> ./users/fred.ttl
>
> The result (given appropriate conneg support), could be served
> directly from something like Apache, just drop it into /var/www/
>
> (my motivation was in part archiving, in part caching)
>
> So I was wondering about the minimum necessary to package such a
> dataset up as SCP, and/or whether SCP could take advantage of that
> kind of setup by using a single meta/manifest file around the root
> somewhere..?

Interesting case to think about. This is certainly the kind of thing I
think SCPs would be helpful with.  Here's one possibility:

Add the following files to your existing directories:

./users/.scpi/id
./users/.scpi/graph.ttl

In graph.ttl, put statements the relate the fred.ttl and fred.html
Bytestreams (in the SCP ontology) to a common resource (say the URI
for Fred), via a predicate like "represents" from some appropriate
vocabulary. Also indicate their media types at a minimum, maybe with
dc:format. Then you could imagine an Apache module, Java servlet, etc,
that was able to select and serve the appropriate content from the
package by matching what's in the the Accept: header with information
asserted in the package graph.

> Another thing that would be helpful around the docs is description of
> other conventions for packaged content+metadata, e.g. OpenDocument.

Good point. There's certainly similarity in a lot of the ZIP-based
packaging formats and it would be good to distinguish and describe SCP
in that context.

- Chris

Received on Monday, 16 April 2012 19:39:43 UTC