Re: Examples in the LDP primer

On 14 Dec 2013, at 16:29, Nandana Mihindukulasooriya <nmihindu@fi.upm.es> wrote:

> Hi Henry,
> 
> First of all, the examples in the primer will definitely change to reflect the changes that we are discussing in the WG at the moment but we will wait until we get the WG consensus and whatever resolutions are incorporated to the spec. If we try to adapt examples while the discussions are ongoing, that would leads to too much extra work.

That makes sense.

> 
> On Sat, Dec 14, 2013 at 2:01 PM, Henry Story <henry.story@bblfish.net> wrote:
> >  <bugs/> a bt:BugCollection;
> >       bt:hasBugs <1>, ...., <300000>.
> 
> [[ aside for Primer writers:
> minor tweak. Your <1>, ...., <30000> are information resources, so they are documents. And so your
> repository is one of bug reports. Bug Reports are things I imagine can change from being bugs, to being feature
> requests etc... Bugs themselves on the other hand can be duplicates of other bugs. So you can have less bugs than
> bug reports.
> 
> We discussed this a lot in the mailing list and the first examples of the primer do not make the distinction between the information resource and the bug by intention and not because we are confused. It was to keep the examples as simpler as possible. I think everyone in the WG understands that the BugReport/Bug or ProductDescription/Product are not the same thing and they can have properties that might have different values for creator, createdData, licence, copyrights, etc. 

> However, the idea was not to make the examples look more complex than necessary specially to the Web developers who would like to get a grasp of LDP and are not aware about this http range 14 issue. The idea was to introduce the distinction between the information resource and the thing it represent in a later example (Example 3.1) in the primer. As you think the information resource and the thing it represent should always be given separate identifiers and that distinction should always be made explicit, there are set of people who think it can be kept simpler when that distinction is not very important in their use cases.  For example, in the URLs-in-Data [1], they say that it is a decision of the publisher to decide how distinct those two are and model accordingly. Either way, once we have the consensus on three or two new types of containers, we will organize the examples in the primer accordingly and the examples covering SimpleContainer will provide a good starting point. If you still think that all the examples in the primer should make that distinction explicit, we can do a straw-poll in the mailing list or proposal in a telco and modify the spec according to the result. 

I don't think that things are made more difficult by doing them right. All that is needed is to make 
clear in the names of relations when one is speaking of documents. The following does not seem 
to be less clear or difficult to read than the current examples:

[[
<> a bt:BugReportCollection, ldp:DirectContainer;   
   ldp:containerResource <../swfwo#v2>;
   ldp:containsRelation bt:hasBugReport .

<../swfo#v2>
     bt:hasBugReport <1>;
      ....; 
     bt:hasBugReport <300000> .
]]

Furthermore it makes the story consistent. It is then easy to understand when one later
speaks of uris with fragment identifier why they are different, and why for example 
they cannot be manipulated the same way using the HTTP verbs. 

Currently the Primer is confusing all round. It has a relation

bt:hasBug that in example 2.1 relates a container that is a product
description  to a bug report.

[[
 </app/product1/> a bt:Product, ldp:Container;
    bt:hasbug </app/product1/bug3>;
]]

Then suddenly in section 50 the same relation is used to relate a product 
to a Bug.

[[
</app/product1/#it> a bt:Product;
  bt:hasbug </app/product1/bug3#it>;
  bt:hasbug </app/product1/bug4#it> .
]]

I would say that the story and the relations should remain consistent
throughout the document. When a relation relates a product to document
it should make it clear in the relation name, and the same relation should
not be used later to make a relation to an object. 

When the distinction is made it examples should be chosen where these differences
make a clear difference, and stories should be developed that make it clear where
it is important to move out of document space, where human beings have clearer
intuitions about the identity of an object. 

Perhaps an individual Product and a Product Description would be a good case. 
The individual product can be sent to someone by post, can have arrived or
not have arrived, can break etc...


>  
>  Furthermore bt:hasBugs sounds like a relation from one to many, whereas in RDF it is a relation from
> one to one - so the relation should really be bt:hasBugReport .
> 
> We agree on this and the property used in the Primer "hasBug" from day one not "hadBugs".
> 
> Best Regards,
> Nandana
> 
> [1] - http://www.w3.org/TR/urls-in-data/#landing-pages

Social Web Architect
http://bblfish.net/

Received on Saturday, 14 December 2013 20:21:10 UTC