Re: Proposal for containers - Feeds and Entries

On 31 Jan 2013, at 18:22, "Wilde, Erik" <> wrote:

> hello henry.
> On 2013-01-31 18:02 , "Henry Story" <> wrote:
>> On 31 Jan 2013, at 16:59, "Wilde, Erik" <> wrote:
>>> everything in atom is an entry or a feed, that's true. but similarly,
>>> everything in LDP is a container or an entry, or is that incorrect?
>> There is no notion of atom:Entry in LDP. So one has to do some knowledge
>> engineering to work out what would be an entry.
> sorry for the confusion, i did not want to say that everything in LDP is
> an atom:Entry. i just wanted to say that LDP has the same model of saying
> that things are collections (they have the capability of containing
> things), or they are contained in collections and need to stick to the
> rules of contained things.

In the mail to which you are responding I answered in detail why the LDP
model is not the same as the Entry model - though it could have been:

You cut out all the argument I put forward with regards to that from your
It is because of these mistaked with Atom, that you are having trouble
creating collections inside collections. This and many other issues
are related to the Atom group having excluded modelling.

> (( and then we also could have that "external content through
> aggregation", but since interactions with these things are outside of the
> scope of the protocol because we only link to them, we don't need to be
> concerned with their representations. ))
>>> assuming that this is indeed the fact, then we should represent that in
>>> the protocol.
>> You would write that in the ontology.
> in which ontology? when do i need to consult this to be able to use the
> protocol? we cannot have anything that requires runtime access to or
> interpretation of ontologies.

Have you heard of caches? That's the core of Roy Fieldings thesis on REST.
The whole point of the web is that you can cache easily. Well known
ontologies should not be donwloaded: they should never change once stable.

>> The other way is to force people to publish information in a specific
>> way, by specifying profiles as you suggested. An  awol:Feed would be
>> a document whose graph *must* contain certain relations. This is what
>> some other people seem to  want too. It would be worth investigating
>> if it is really needed.
> i guess this is what i am trying to say.
>> But the problem with that is that you are unlikely to get people
>> to follow correctly. So it may just be better to have hwo the realtions
>> are put together determined on the field.
> why is that? the protocol specifies the required information that must be
> and can be exchanged, and then peers can interoperate. if they don't
> follow the rules, the server responds with 4xx errors. a test suite could
> contain some variety of positive and negative tests, along with
> expectations of how a compliant server would have to behave.

Ok, so I already told you today to put open an issue if you feel serious 
about it. 

>> That does not contradict my argument, which was on the impossibility
>> of extending this technique to rdf, not on the impossibility of removing
>> the technique.
> i still don't see what is impossible about it. we require representations
> to be self-describing, and if they aren't, it's a protocol error. RDF can
> do that in the same way as XML or JSON can do that: you specify
> constraints (formally or in prose), implementations need to check for them
> (is such a triple in there), and you're done. i guess in our case we could
> even specify constraints in SPARQL to have formalism for them. not that
> they would have to be implemented that way, but i don't see what would be
> hard about this.

Look, if you want to put forward mime types of turtle types please put that
forward as an issue. I have said what I had to say.

> cheers,
> dret.

Social Web Architect

Received on Thursday, 31 January 2013 17:40:00 UTC