- From: David Wood <david@3roundstones.com>
- Date: Tue, 11 Feb 2014 08:08:53 -0500
- To: Cody Burleson <cody.burleson@base22.com>
- Cc: Steve Speicher <sspeiche@gmail.com>, Linked Data Platform WG <public-ldp-wg@w3.org>
- Message-Id: <11DC9558-444A-4738-B7B7-5730E1E58017@3roundstones.com>
Hi all, On Feb 10, 2014, at 16:14, Cody Burleson <cody.burleson@base22.com> wrote: > Right! > > So, that's 3 additional triples for each container. For what it is worth, this seems to me to be a simple question of where resources go. In our experience it often makes sense to materialize useful triples (paying the cost of storage and indexing) instead of inferencing at runtime (thereby avoiding the cost of time and computation). What exactly is the argument to the contrary in this particular case? I propose that we should be viewing this as a simple engineering trade-off. Inferencing is (IMO) best used in systems when the information is not often sought, e.g. when it is useful to a relatively small population, or when it is impossible to judge in advance which information someone might need. Materialization is best used when the information is expected to accessed regularly during runtime. Regards, Dave -- http://about.me/david_wood > 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. > >
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Tuesday, 11 February 2014 13:09:17 UTC