Re: Creating non-Atom LDPRs: AtomStrict & AtomRelax

Thanks for summarising my mail Steve. Just to answer your questions below
that relate to ISSUE-10 and ISSUE-15

On 3 Feb 2013, at 17:17, Steve Battle <steve.battle@sysemia.co.uk> wrote:

>> The container, will be much more secure by restricting  itself to the second.    
> 
> So member metadata should be asserted within the RDF representation of the container itself. 

I think SHOULD is reasonable yes. How much will vary very  from application
to application. But it will certainly help to say something about the objects 
in the container, so that agents browsing it can navigate it efficiently. 
My guess is that everything the document says about itself, such as 

{ <> a foaf:PersonalProfileDocument . } 

is the type of thing that can go in too, though care should be taken...

If in the examples in the spec one wanted to do that immediately
without waiting for us to build up an atom-ontology, the one to take would probably
be dublin-core. I remember in during the atom spec elaboration there being a 
post that showed there was pretty much a one to one mapping between atom and DC. 

> I wonder also, if the entity tag should properly be thought of as part of the explicit metadata of an LDP Resource (and not part of the LDP resource data - that gets very circular, very quickly).

Why not. Other than that the etag information may be too sensitive to very minor changes.
atom:updated allows tiny minor updates without needing the date to change.

> This begs the question; is every LDP Resource member of an LDP container, which provides a natural home for it's metadata? Maybe they should be.

The ldp:Container is a good place to get aggregated metadata. For individual
item metadata, it makes sense to have a seperate resource, what atom
calls the edit-meta link. I would just call it :meta

----------------------------------
GET /account/ HTTP/1.1
----------------------->>
<> a ldp:Container;
  rdfs:member <jack> .

<jack> a foaf:PersonalProfileDocument, ldp:Resource;
      :title "Jack's personal Profile";
      :id "http://drinks.example/account/jack";
      :updated "2013-02-02T16:34:06Z"^^xsd:dateTime;
      :meta <jack;meta>;
      :acl <jack;acl> ;
      :author <jack#i>  .
----------------------------------

now the :meta or :acl should point to the same resources
one gets when one does a HEAD on the resources itself, using
RFC5988

--------------------------------------
HEAD /account/jack HTTP/1.1
-------------------------->>
HTTP/1.1 200 Ok
Link: <jack;acl>; rel=acl
Link: <jack;meta>; rel=meta
--------------------------------------

A nice server could even have <jack;meta> return at 
atom entry representation, as well as a Turtle one
depending on was requested.

With a good PATCH mechanism we get the edit functionality
of the metadata out of the box if needed. If you want to change
the title of the resource PATCHing the <jack;meta> sound like the
reasonable way to do that.... I'd say this is server dependent
and optional.

Specifying the vocabulary to use would be good though so that
clients can know what properties they should try to look for.

Henry

Social Web Architect
http://bblfish.net/