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

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".

- 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

* <http://base22.com>*
*
*
*Check my free/busy
time.<http://www.google.com/calendar/embed?src=cody.burleson%40base22.com&ctz=America/Chicago%20>
*