Re: Proposal for containers

On 1/31/13 9:47 AM, Wilde, Erik wrote:
> hello henry.
>
> On 2013-01-31 13:28 , "Henry Story" <henry.story@bblfish.net> wrote:
>> Why not have your service document do something like this
>> <> xyz:service <http://ldp.example/> .
>> <http://ldp.example/> a ldp:Container .
>> And then if you want to specify the media types available on that you
>> could add
>> <http://ldp.example/> xxx:mime "application/atom+xml", "text/turtle" .
>> If it wants to link to another service it could write:
>> <> xyz:service <http://ldpng.example/> .
>> <http://ldpng.example/> a ldpng:Container .
>> See nothing special here.
> that works on the semantic web (where you expose things via RDF), but not
> on the web (where you have to live with HTTP's uniform interface).

Hmm.  that's a false dichotomy. The Web is a graph of Linked Data. What 
varies is the Content-type of resources.

The Web as an Information Space is dominated by HTML content.

The Web as a Linked Data space is dominated by RDF model based content, 
the Content-types vary since the model and serialization formats are 
distinct. Same applies to notations used for structured data 
representation.

The Web is/has/will always be a Giant Global Entity Relationship Graph. 
The only variable is fidelity delivered by Content-types. For instance 
HTML is coarse and RDF model based Content-types are fine-grained.

All we want is the is a clear path to the Datum (a triple base 
proposition) that comprehensible to humans and machines. We seek the 
ability to maximize the combined capabilities of humans and machines by 
playing to their respective strengths.



>   let's
> look at a more condensed example: a server providing a variety of
> collection management services at the same URI, just because this is
> possible and it's kind of cool to always use the same URI for the
> collection, regardless of whether it's accessed through LDP or AtomPub or
> LDP-NG.

"Cool" is all about virtues abstraction and indirection when applied to 
data representation, access, integration, and dissemination.

For instance, what makes an ODBC or JDBC data source name (DSN) 
valuable? The fact that all data access is scoped to a Name denoting the 
source of data hosted by an RDBMS. Thus, when the back-end DBMS changes 
the ODBC or JDBC compliant clients don't need to be altered. RDF based 
Linked Data builds on that basic virtue by enhancing the age-old Entity 
Relationship model with *explicit* human and machine comprehensible 
entity relationship semantics. Thus, instead of an RDBMS  specific data 
access mechanism, or operating system specific ODBC DSN, or a 
programming language specific JDBC DSN,  I have an HTTP URI that 
delivers enhanced value by moving this name abstraction exploitation to 
any HTTP user agent --my browser (or any other user agent) becomes my 
Microsoft Access or Excel Report writer, so to speak.

> a client would access that URI with a GET or POST, and then could say what
> it accepts in an HTTP Accept header (or what it POSTs in a Content-Type
> header), listing media types to allow the server to respond appropriately.
> the scenario here is the same as in my example about the service document,
> but you really have no vocabulary other than media types, because that is
> what HTTP uses (http://tools.ietf.org/html/rfc2616#section-14.1).

As Henry (and I) have indicated, there could be a useful binding point 
via profiles. Thus, one could look to the combination of Content-type 
and profile to deliver the context clarity for an LDP service provider 
that understands RDF (the model, syntax, and at least one of its content 
creation markup languages or notations) .
>
> cheers,
>
> dret.
>
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen