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

Please allow me to "think out loud" for a minute here, at the risk of being
somewhat verbose.

I can appreciate the point you've made about this being an engineering
trade-off. But, I also believe that the engineering mindset has worked
against adoption of Linked Data from day one. As I see it, Linked Data
Platform is supposed to be an answer to the otherwise large or difficult
barrier to entry that has mired adoption of semantic web technologies.
Linked Data Platform should provide an old hat familiarity to the average
web developer and, if we succeed - even the below-average web developer.

On this point I am trying to represent the kind of person that knows just
enough to tweak his WordPress theme over a weekend. Someone who may be
working with jQuery Ajax to formulate REST calls to an LDP Server and who
will ask, "Why do I have to include ldp:Resource? Of course, it is an LDPR
- it's an LDP Server... what else is there?" I was just thinking that this
person may find it utterly annoying to have to send these triples over the
wire, or parse them, when the context is just within one LDP Server.

But, there are two contexts that I can think of: working in one LDP Server,
and the broader Web.

ONE SERVER (Got my blinders on...)

You say, "it often makes sense to materialize useful triples." But I don't
see how, when all things are an ldp:Resource, that is actually a "useful"
triple. In my opinion, the only reason to have any concept in a system is
if that concept is differentiated from other concepts. For us, anything
that goes into or comes out of the LDP server will necessarily be an
ldp:Resource. So, how will we ever use that concept? I will never formulate
a query, for example, that says, "Select everything that's an
ldp:Resource." I'll get back everything! And of course, there's also
nothing that's NOT an ldp:Resource, so I can't query for that either. I
guess I am saying that in the context of one single LDP Server, the concept
seems unnecessary to explicitly declare.

WWW (Blinders off...)

In the context of some broader ontology, or say - with open Linked Data on
the WWW, the class hierarchy may be useful. In that context, an
ldp:Resource is differentiated from all things that are not ldp:Resource
and they are loosely defined as "a resource that is managed by an LDP
compliant server." If in the broader context, I cannot assume the resource
lives on an ldp:Server, then I don't see how the concept is useful there
either. But I do think it may be useful there. I can certainly see
traversing the Web of Linked Data and knowing when I am within the domain
of some LDP server.

So... following this line of thinking, I would probably use the following
implementation strategy (given that our underlying datasource is a
triple-store):

1. Do not require the use of ldp:Resource in the entity body because it is
always implied when submitting to an LDP Server.
2. Accept ldp:Resource if it is included in the entity body because, it's
true.
3. Do not store the triple ldp:Resource because it is always implied and
that's just a waste of resources.
4. Serve the ldp:Resource triple in the response to GET requests because
you can never know that the context of the request isn't broad.
5. Etc. (same general strategy) for containers.

So, this wouldn't change the spec much. In this case it would be nice to
say that it is not required to use ldp:Resource or ldp:Container in the
entity body of a POST or PUT, but you MUST materialize them in response to
a GET.

Sorry to be so verbose; just "chewing on this" with you.

Thoughts ???

- Cody



On Tue, Feb 11, 2014 at 7:08 AM, David Wood <david@3roundstones.com> wrote:

> 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
>>>
>>> * <http://base22.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.
>>> <http://www.google.com/calendar/embed?src=cody.burleson%40base22.com&ctz=America/Chicago%20>*
>>>
>>>
>>>
>>
>
>
> --
> Cody Burleson
> Enterprise Web Architect, Base22
> Mobile: +1 (214) 537-8782
> Skype: codyburleson
> Email: cody@base22.com
> Blog: codyburleson.com
>
> * <http://base22.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.
> <http://www.google.com/calendar/embed?src=cody.burleson%40base22.com&ctz=America/Chicago%20>*
>
>
>
>


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

* <http://base22.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.
<http://www.google.com/calendar/embed?src=cody.burleson%40base22.com&ctz=America/Chicago%20>*