Re: Proposal for containers - Feeds and Entries

hello henry.

On 2013-01-31 18:02 , "Henry Story" <henry.story@bblfish.net> wrote:
>On 31 Jan 2013, at 16:59, "Wilde, Erik" <Erik.Wilde@emc.com> 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.

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

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

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

cheers,

dret.

Received on Thursday, 31 January 2013 17:23:19 UTC