W3C home > Mailing lists > Public > public-ldp-wg@w3.org > December 2013

Re: Examples in the LDP primer

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Mon, 16 Dec 2013 12:17:14 -0500
Message-ID: <52AF359A.40109@openlinksw.com>
To: public-ldp-wg@w3.org
On 12/16/13 11:53 AM, Roger Menday wrote:
>
> hello Kingsley,
>
> I'm just saying that we should either :
>
> * make it clear that whilst we use UR*L*s for "Zaza the Cat", we 
> understand what we are doing here :)

We shouldn't use URLs to denote anything that isn't a Web accessible 
resource (e.g., Web pages, images, audio, video ). Using URLs to denote 
entities that aren't Web accessible resources is simply unjustifiable, 
anywhere that exists.

> * change all examples (across all documents) to do it the "proper" way.
>

+10000

Yes!

[1] http://bit.ly/WAJGCp -- it the easy way to go
[2] 
http://media-cache-ec0.pinimg.com/originals/54/72/14/5472143ff41989fa59735e86777dcced.jpg 
-- big picture.

Kingsley
> Roger
>
>
> On 16 Dec 2013, at 16:35, Kingsley Idehen wrote:
>
>> On 12/16/13 8:57 AM, Roger Menday wrote:
>>>
>>> Regarding what the Spec says about Things vs. Documents-about-Things 
>>> ... I think we are little vague.
>>> Maybe this is intentional, but my feeling is that it would be better 
>>> if we were more transparent.
>>>
>>> Roger
>>
>> HTTP URIs denote anything.
>>
>> HTTP URLs are HTTP URIs that denote documents.
>>
>> WebIDs are HTTP URIs that denote agents (people, organizations, 
>> software, robots, and anything else capable of mechanized operation).
>>
>> These are fundamental facts re., Web Architecture, RDF, and RDF based 
>> Linked Data.
>>
>> "Things vs Documents" does confuse the matter. The issue here is 
>> simply one of denotation using different kinds of HTTP URIs.
>>
>> The spec has no reason to not reflect this reality. The same applies 
>> any examples.
>>
>> Kingsley
>>>
>>>
>>>
>>> On 14 Dec 2013, at 15:29, Nandana Mihindukulasooriya 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.
>>>>
>>>> On Sat, Dec 14, 2013 at 2:01 PM, Henry Story 
>>>> <henry.story@bblfish.net <mailto: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.
>>>>
>>>>      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
>>>
>>
>>
>> -- 
>>
>> Regards,
>>
>> Kingsley Idehen	
>> Founder & CEO
>> OpenLink Software
>> Company Web:http://www.openlinksw.com
>> Personal Weblog:http://www.openlinksw.com/blog/~kidehen
>> Twitter Profile:https://twitter.com/kidehen
>> Google+ Profile:https://plus.google.com/+KingsleyIdehen/about
>> LinkedIn Profile:http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen







Received on Monday, 16 December 2013 17:17:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:54 UTC