Dev comments on the primer

During last week's meeting, the Primer owners solicited comments.  Here's 
what I got back from a small set of folks who definitely care, but are not 
as polluted by LDP's details as WG members.

Dev DN:  has never read the LDP spec.  Has implemented "notionally 
similar" collections in one product x 2 generations.

I like the softer-than-spec style, it reflects the reality of a larger 
swath of the development community nowadays (and that is not 
a veiled criticism to the new crop of developers) .

About "Lookup a Product (LDPC?)"  I think there is an unexplained hop, 
from inferring that bt:hasbug links are links to the bugs.
Linked data is beautiful if the metadata behind the data is known by both 
parties, so that it may be useful to clarify (1) that the point 
was intentionally left out or (2) introduce the explanation about how both 
applications would know about it ahead of time. 

OSLC answers that question with resource shapes and their ties to query 
capabilities returning the data, but not sure how that same 
type of metadata is shared in the lower (higher?) layers of a pure LDP 
world.



Dev JR: deeply reviewed the LDP LC spec, and was the source of some of the 
comments I related during the F2F.  Dev lead for DN's project.

Up until now, we [Arwe: one component] have had a model that the RDF state 
of an HTTP resource (LDPR) is represented by a single top-level RDF 
resource with other in-line RDF resources accessible from it by links. I 
don't know if other readers of the LDP spec might be coming in with the 
same mental model, but it might be useful to clarify that the RDF 
representation of an LDPR can consist of multiple RDF resources which may 
or may not be linked to each other. It's really just a list of triples, 
and the subject of those triples may or may not be the URL used to access 
the LDPR.


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario