On 18/07/13 20:45, Sergio Fernández wrote:
Hi,
I've just add my revision at jira:
Just so you know:
[[
Personally I still have some questions, particularly about LDPCs, but
now it is not the right time to put them on the table...
]]
It is the right time. It's now, or during the last call period, or
never. Now is better.
Andy
On 18/07/13 21:22, Jakob Frank wrote:
these are my first comments, after I had a quick look into the draft [1]:
* LDP declares dct:modified and dct:creator as (optionally)
server-controlled (managed) properties. The dct-vocabulary is
wide-spread and used in many applications, declaring it managed will
break many of them. There is a ldp-vocabulary, why not use
ldp:modified / ldp:creator for this purpose? [Section 4.4]
This was discussed quite long ago, I'd have to find the concrete issue.
I disagreed on mixing metadata about the resource and about the server,
but the best we got is to use "MAY" there. So I'd expect 4.4.1 will be
ignored in many different implementations.
* for paging (cool feature!), LDP defines links to the next page using
ldp:nextPage (and a corresponding HTTP Link-Header) to indicate the
URI of the next page. Is there a reason not to also include the links
ldp:prevPage, ldp:firstPage, ldp:lastPage? [Section 4.9]
I think the followed the simple linked list structure for representing
pages.
Maybe we can suggest to add something like "The page resource
representation MAY have triples with the subject of the page, predicates
ldp:prevPage, ldp:firstPage or ldp:lastPageof and object being the URL
for the respective pages."
* for a non-LDPR POSTed to the LDP server, the server may create a
corresponding LDPR. The non-LDPR may Link (HTTP-Header) to it's
associated LDPR using the "meta"-relation - why not add the also an
inverse Link (HTTP Header) using e.g. the "content"-relation? [Section
5.4]
Good point.
* my general impression is that in several places (especially with
paging [Section 4.9] and inlining [Sections 4.10 and 5.10]) server
responses mix data and request-specific meta-data (e.g. navigation
links with paging, etc...). I have no alternative proposal but still
this feels somehow "soiled" (sorry, did not find a better wording).
Those two particular parts are clearly less evolved that the other. For
sure something to work on the next version.
Probably these issues were discussed lengthily in the WG, maybe
someone more involved there can share some insights?
Unfortunately I missed the last calls; but maybe Nandana or Andy could
provide you some more information.
If no one else has any additional comments, I think we should send these
comments to the WG tomorrow.
Cheers,
