Re: Issue-71: the first bug tracking example

On 22 May 2013, at 09:34, Roger Menday <> wrote:

>> > > 
>> > > So let me here try to bypass this problem and see how far I can go. 
>> > > Let us say </bugs/> is our container with the following content:
>> > > 
>> > > ~~~~~~~~~~
>> > > <> a ldp:Container, bt:BugReport;
>> > 
>> > This should be named something like bt:BugReportContainer rather 
>> > that bt:BugReport. 
>> Indeed. I guess your proposal isn't immune to confusion either, is it? ;-) 
>> > One could perhams even use owl Restrictions to define a class like that.
>> > 
>> > >  val:primaryTopicRestriction [ onProperty bt:product
>> > >                                hasValue  <
>> > BugTracker/ProductA> ]; 
>> > 
>> > So again this is a restriction of the primaryTopic of the members of
>> > the container.
>> > another name could be val:memberPrimaryTopicRestriction .
>> > 
>> I have to admit not to understand what this has to do with the question at hand. And if we can't defined LDP without OWL we've failed. 
>> > >   bt:member <bug1>, <bug2>, <bug3> . 
>> How does a client know that bt:member is the predicate used in your container to list the member resources? 
>> Given your criticism of Nandana's modeling shouldn't you list bug reports in your container rather than bugs here? 
> According to my reading of Henry's email, the <bug1>, <bug2>, ...  resources above are informational resources and are bugreports. Resources such as <bug1#x> are bug resources. So, I think he is actually listing bugreports with rdfs:member in the above example. 

yes. my typo. bt:member should have been rdf:member .

> But, I want to use LDP to manage links between things, using domain vocabulary - so, I'm not so sure if I can agree with what Henry is saying :) 

Of course one should be able to manage links between things. But nothing stops that from hapenning.
Everytime you POST a new BugReport to the bug container, a different rdf:Container could have a new
relation added to it. There may be all sorts of things that can happen when you change resource
on the container. One could have a vocabulary for each of those things. So one could have 

<#bugs> rdf:member <bug1#y>, <bug2#y>, <bug3#y>, <> .

Since this is just rdf data you can very easily also tie together information from different bug databases
together, edit them using PATCH, etc... This structure can be generated automatically by the 

In SQL terms an LDPC is closer to the creation of a table. Every other data structure can 
then be placed inside of tables. There is a need for the server and the client ( potentially 
administration clients ) to be able to know what the tables ( LDPRs ) on their servers are 
without needing to know about the content. If LDP does this then it has already

> I think that the argument around modelling is also coming to Networth next. i.e. I can see a similar argument applying to Networth and NetworthReport. Henry ? 

very likely. 

> Again, I'm of the opinion that if people want to coalesce their information and 'real' resources, then LDP shouldn't stop them from doing that. 

We can't stop people from bad modelling, like you can't stop people from saying nonsense
online or elsewhere.  But  this is a WG and here all the examples in the specs we produce have
to be irreproachable.  It also helps to make things clear from the get go, because that is the
way to allow us to better see missing elements in the spec. Also good modelling will lead to 
a better spec.

If you don't model things correctly you are going to just loose the ability to set copyrights 
on your data, explain access restrictions, explain prices correctly, explain what you want
to DELETE etc... Now my guess is that a lot of major corporations would like to do those
things, as well as governments and charities. Some want to charge for their data, others
give it away free. The data may be free but the objects they refer to expensive or vice
versa. Just to say there is money involved.

> Roger

Social Web Architect

Received on Wednesday, 22 May 2013 09:10:04 UTC