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

Re: Section 4: LDPR/non-LDPR formal definitions

From: Richard Cyganiak <richard@cyganiak.de>
Date: Fri, 22 Mar 2013 15:30:41 +0000
Cc: Cody Burleson <cody.burleson@base22.com>, public-ldp@w3.org
Message-Id: <F31F450A-7BEE-42FE-B102-E3640B27801B@cyganiak.de>
To: Henry Story <henry.story@bblfish.net>
An LDPR is an HTTP-accessible resource that has a Turtle representation (and meets some additional requirements, as defined in the LDP spec). The “binary or text resources” we're talking about here are HTTP-accessible resources that have non-RDF representations. Since an HTTP-accessible resource can have multiple representations (a.k.a. content negotiation), there is no reason to presume that these two classes of resources are disjoint. There might be resources that are both LDPRs and binaries/images/text resources. I don't think that we need to say anything about this in the spec. But I don't see a reason for forbidding such uses of HTTP by specifying a class of “non-LDPR” resources.

Best,
Richard



On 22 Mar 2013, at 15:03, Henry Story <henry.story@bblfish.net> wrote:

> 
> On 22 Mar 2013, at 15:50, Cody Burleson <cody.burleson@base22.com> wrote:
> 
>> What is the question about whether binaries (images, etc) are non-LDPRs or if they too are LDPRs?
>> 
>> In the specification, I can find only one reference to non-LDPRs, which states:
>> 
>> 4.1.3 LDPR servers MAY host a mixture of LDPRs and non-LDPRs. For example, it is common for LDPR servers to need to host binary or text resources that do not have useful RDF representations. 
>> 
>> There is no other mention of non-LDPR except in the editor's notes, which say:
>> 
>> 4.1.2 (if "the code" == LDPR server) could be read to say that in order to conform to spec it must serve up RDF for non-LDPRs. Hits 5.2.1 too. 
>> 
>> I could not find an open issue that seems to relate to this question. Is there an open issue?
>> 
>> It seems like you may be suggesting that it could be useful or necessary to return some sort of RDF representation of ANY resource stored on an LDPR server. 
>> 
>> It seems to me that if there is an RDF representation of a binary file, then the RDF representation is itself the LDPR, but the binary file is, by definition, a non-LDPR. (When i say, "by definition", I just mean: so far as the spec has currently created that definition in section 4.1.3).
>> 
>> I'm just still trying to learn and wondering if you could elaborate on "the question".
> 
> Ok. So there are non-LDPRs: binaries. We have a use case for binaries. So we have a
>  use case for non-LDPRs.
> 
>> 
>> - Cody
>> 
>> 
>> 
>> On Fri, Mar 22, 2013 at 8:52 AM, Henry Story <henry.story@bblfish.net> wrote:
>> 
>> On 22 Mar 2013, at 14:37, Martynas Jusevičius <martynas@graphity.org> wrote:
>> 
>> > You're right, I don't have a use case for non-LDPRs at hand. The main
>> > topic of this issue was the definition of LDPR. Isn't it about time to
>> > make it explicit, and in general flesh out more the LDP ontology?
>> 
>> There is still a question whether binaries (images, etc) are non-LDPRs
>> or if they too are LDPRs.
>> 
>> >
>> > On Fri, Mar 22, 2013 at 3:19 PM, Richard Cyganiak <richard@cyganiak.de> wrote:
>> >>
>> >> On 22 Mar 2013, at 12:59, Martynas Jusevičius <martynas@graphity.org> wrote:
>> >>> Let me rephrase -- is the following true
>> >>> in the LDP ontology?
>> >>>
>> >>> ldp:Resource rdfs:subClassOf foaf:Document
>> >>
>> >> Personally I think it is. However, that implies consent with the TAG's httpRange-14 decision, which is, shall we say, controversial. I think it would be ideal to define LDP in a way that is agnostic with regard to httpRange-14.
>> >>
>> >> I'm also unsure whether we want to explicitly assert relationships with FOAF, given that LDP as W3C product has a good chance of outliving FOAF.
>> >>
>> >>>> I cannot think of any use case for the class of non-LDPRs. You seem to think that there is a use case for it, that's why I asked you to state the use case.
>> >>>
>> >>> My use case would be to extend LDP ontology and/or create instances of
>> >>> its classes.
>> >>
>> >> That's not a use case.
>> >>
>> >> Why would you want to extend the LDP ontology in a way that requires a non-LDPR class? And why would you want to create instances that require a non-LDPR class?
>> >>
>> >>>>> There is an ldp: namespace
>> >>>>> and seems like there is an ontology also, why shouldn't it include a
>> >>>>> definition of ldp:Resource alongside of ldp:Container, ldp:Page etc.?
>> >>>>
>> >>>> Of course, but why should it include ldp:NonLDPR?
>> >>>>
>> >>>>> And if LDPRs and non-LDPRs are disjoint, why not make it explicit as
>> >>>>> well?
>> >>>>
>> >>>> Of course LDPRs and non-LDPRs are disjoint. Again, that's trivially true, it's a tautology. X and non-X are disjoint regardless of what X is. I don't see the point in explicitly stating trivially true facts.
>> >>>
>> >>> Trivial for humans, but not for machines?
>> >>
>> >> A machine has no trouble whatsoever figuring out that the classes X and (not X) are disjoint.
>> >>
>> >> Stating tautologies to machines is even less pointless than stating them to humans.
>> >>
>> >>> Isn't that the purpose of ontologies, to explicitly define facts? Even if they're trivial.
>> >>
>> >> The purpose of every ontology is different. Some ontologies have no purpose at all.
>> >>
>> >> You still haven't given any reason why the class of "things that are not LDPRs" would be useful. It seems to me that you're trying to evade the question by stating generalities. Can you give a concrete use case for such a class that helps in delivering some concrete benefit to some class of end-users?
>> >>
>> >> Best,
>> >> Richard
>> >
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 
>> 
>> 
>> -- 
>> Cody Burleson
>> Enterprise Web Architect, Base22
>> Mobile: +1 (214) 702-6338
>> Skype: codyburleson
>> Email: cody@base22.com
>> Blog: codyburleson.com
>> 
>> <base22.gif>
>> 
>> Check my free/busy time.
>> 
>> 
> 
> Social Web Architect
> http://bblfish.net/
> 
Received on Friday, 22 March 2013 15:31:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:10 UTC