Re: Proposal for containers - Feeds and Entries

On 31 Jan 2013, at 16:59, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:

> hello henry.
> 
> On 2013-01-31 12:43 , "Henry Story" <henry.story@bblfish.net> wrote:
>> LDPRs which can be any type of RDF groph. In RDF the type of  the <>
>> document
>> can be infinite. It could be a foaf:Document,
>> foaf:PersonalProfileDocument,
>> ldp:Container, ldp:Resource, mony:ShoppingCart, ...
>> In atom there are only two types atom:Entry and atom:Feed.
> 
> 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. 

LDP 
---

In LDP we have two classes of things: LDPRs and LDPCs, and LDPRs are a 
subclass of LDPCs, as explained here (revealing the mysterious LDPX )

http://www.w3.org/2012/ldp/wiki/images/b/b5/LDP-RCX.pdf


That is clean and powerful. It means that as a result we can 
create Containers inside of containers automatically. And all
kinds of other goodies. 

Atom
----

I initially argued in 2004 that a atom:Feed was an atom:Entry
and published the following UML diagram showed, and Java code
to go with it.

  http://bblfish.net/work/atom-owl/2004-06-22/Atom-June-25-UML-inherited-simple.jpg

But you will see that this created a huge traffic because of confusion
between the model and the syntax on the mailing list (search for
"feed is an entry" in this thread:

  http://comments.gmane.org/gmane.network.syndication.atom.syntax/6558

In the end I decided to model what was the case not what would it 
would have been sensible  to have. So the AtomOWL ontology I came
up with looks like this in UML ( see the "at a glance section" )

  http://bblfish.net/work/atom-owl/2006-06-06/AtomOwl.html

As you can see there there are properties that are in common to 
Atom Entry and AtomFeed. I put those on the FeedOrEntry class. 
Things are just not neat there, because there was no desire to think
about the ontology or even the UML diagram when writing the atom spec.
Essentially the people working on that seemed to come from HTML space
and had never heard of uml diagrams, or any type of modelling.
In fact modelling was outlawed in the group pretty quickly.

Conclusion
----------

So as a result things don't quite match. I think it would make sense
to have an ontology where

awol:Feed rdfs:subClassOf ldp:Container .

awol:Entry rdfs:subClassOf [ 
           a rdfs:Class;
           rdfs:label "LDP_:X";
           owl:intersectionOf ( [ owl:complementOf ldp:Container ] ldp:Resource ) 
   ] .

Ie, awol:Entry is a subclass of the myserious LDPX. 


> assuming that this is indeed the fact, then we should represent that in
> the protocol.

You would write that in the ontology.

> if not, then i am wondering how a client would be able to
> find entries when it gets, for example, the contents of a container and
> expects to be able to locate entries.

You get a document, transform it to a graph, then you can query
it in a number of ways.  Say you got your graph g from uri loc
then some library such as https://github.com/w3c/banana-rdf/tree/ldp

would allow you to do 

 val pg = PointedGraph(loc,g)
 val ldprs = pg/rdf.member
 then you can get information about each ldpr. If there is not
enough in the graph, you dereference the URIs and get more information.

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.

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.


> 
>> So given that application/atom+xml can only contain two subtypes
>> it is just about ok to put it in the mime/type of the header.
> 
> but they don't need to be there. it's optional per the protocol

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.

> 
> cheers,
> 
> dret.
> 

Social Web Architect
http://bblfish.net/