Re: To spec editors - regarding possibly redundant rdf:type definition of containers in examples

Well, I'm glad you brought this up. I said the same thing to Steve and 
John. I think they are reading too much into the clause about not 
requiring inferencing.

I don't read this clause as meaning we can't expect a client to know that 
an ldp:BasicContainer is an ldp:Container and that therefore the latter 
doesn't need to be materialized.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group




From:   Cody Burleson <cody.burleson@base22.com>
To:     Steve Speicher <sspeiche@gmail.com>, 
Cc:     Linked Data Platform WG <public-ldp-wg@w3.org>
Date:   02/10/2014 01:15 PM
Subject:        Re: To spec editors - regarding possibly redundant 
rdf:type  definition of containers in examples



Right!

So, that's 3 additional triples for each container.

Though we reluctantly accept that it may currently be necessary as we've 
written the spec, it doesn't feel too good.

In our world-view, we would not need inferencing to tell us that the 
variants of an LDPC are also LDPRs or that any single variant is also an 
ldp:Container. In any query we formulated on the client side, it's not too 
much for us to put two and two together. 

I don't know which is better. To do the extra work on the client or store 
a bunch of redundant triples.

- Cody





On Mon, Feb 10, 2014 at 3:03 PM, Steve Speicher <sspeiche@gmail.com> 
wrote:
On Mon, Feb 10, 2014 at 4:00 PM, Cody Burleson <cody.burleson@base22.com> 
wrote:
That makes sense, thanks!

But given that logic, mustn't we also need to specify that it is an 
ldp:Resource? 

For example:

<>
   a ldp:Resource, ldp:Container, ldp:BasicContainer;

Thoughts?
 
touché

Actually yes but ldp:RDFResource also ;).  Perhaps we need that augmented 
rule.  What do you think?

Thanks,
Steve Speicher





On Mon, Feb 10, 2014 at 2:43 PM, Steve Speicher <sspeiche@gmail.com> 
wrote:

On Mon, Feb 10, 2014 at 3:28 PM, Cody Burleson <cody.burleson@base22.com> 
wrote:
The specification says that an LDPR cannot be just an ldp:Container; it 
must be either of a ldp:BasicContainer, ldp:DirectContainer, or 
ldp:IndirectContainer. Since these three classes are expected to extend 
ldp:Container, we think it is questionable to define resources in the 
examples with both ldp:Conatiner AND one of the three types.

For example, take a look at example 3 in Section 6:

<>
   a ldp:Container, ldp:BasicContainer;

We suppose there is nothing invalid or illegal about this redundancy, 
but... what's the point of the additional redundant triple? If it is a 
BasicContainer, DirectContainer, or IndirectContainer, can we not always 
assume it is also an ldp:Container without the need for another triple 
explicitly stating that?

Hey Cody,

We have this redundancy due to the following rule [1]:

[[
5.2.9 LDP servers must not require LDP clients to implement inferencing in 
order to recognize the subset of content defined by LDP. Other 
specifications built on top of LDP may require clients to implement 
inferencing [RDF-CONCEPTS]. The practical implication is that all content 
defined by LDP must be explicitly represented.
]]

We could decide to augment this rule, to say something of the spirit of 
"except in the case of ..."

[1] - 
https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpr-gen-noinferencing

Regards,
Steve Speicher

 


-- 
Cody Burleson





-- 
Cody Burleson
Enterprise Web Architect, Base22
Mobile: +1 (214) 537-8782
Skype: codyburleson
Email: cody@base22.com
Blog: codyburleson.com

Please be advised that I check and respond to mail 
on the following Central Standard Time schedule: 
9:00 am, 12:00 pm, 3:00 pm, and 6:00 pm

Check my free/busy time.






-- 
Cody Burleson
Enterprise Web Architect, Base22
Mobile: +1 (214) 537-8782
Skype: codyburleson
Email: cody@base22.com
Blog: codyburleson.com

Please be advised that I check and respond to mail 
on the following Central Standard Time schedule: 
9:00 am, 12:00 pm, 3:00 pm, and 6:00 pm

Check my free/busy time.