[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xdi] Re: XDI subjects (was Groups - XDI RDF v8 Comments-Barnhill)
My quick&simple solution to this whole thread would be to say that literals have no semantic meaning within XDI itself. They are just data for the consuming application.
So if you really want to say something about the number 24, then you use an XRI, e.g. $24, or $type$xsd$int!24, or whatever.
$24
$is
+( http://example.com/number/of/beers/in/a/case)
Markus
On Thu, Mar 20, 2008 at 3:51 AM, Kermit Snelson < ksnelson@subjectivity.com> wrote:
- These issues are indeed very difficult to discuss over email, so I'm
- all for deferring them to tomorrow's telecon.
- But in the meantime, I do have an easy-to-express-over-email thought about this:
- > Also, the reflexive properties of "is" would seem to hold across any combination
- > of the subjects and objects of these statements
- I'm not yet convinced that does work, actually, even in English. The
- reasoning here:
- The number of beers in a case is 24.
- 24 is the number of hours in a day.
- Therefore, the number of beers in a case is the number of hours in a day.
- is really no better than this:
- Sushi is better than nothing.
- Nothing is better than sex.
- Therefore, sushi is better than sex.
- The problem with the first syllogism (and it's probably already
- obvious that "nothing" is wrong with the second one) is its
- implication that changing the number of beers in a standard case to be
- 16 would also require changing the number of hours in a day to be 16,
- which probably isn't true.
- My point here is that using literals both as subjects and as objects
- can cause problems even in English, and I suspect that's one of the
- reasons why RDF, which is designed to express semantics with
- sufficient precision that even machines can't get confused, allows
- only objects to be literals. And if only objects may be literals, then
- it's impossible to have reflexive predicates, because otherwise
- < http://example.com/number/of/beers/in/a/case> <$is> <"24">.
- would imply
- <"24"> <$is> < http://example.com/number/of/beers/in/a/case>.
- =Kermit
- On 3/19/08, Drummond Reed < drummond.reed@cordance.net> wrote:
- > To me, this is a wonderful example (or painful example, depending on your view) of how some aspects of this subject are going to be difficult to discuss via such a low-bandwidth medium (or at least a slow-bandwidth medium) as email.
- >
- > To be specific, I think I understand the point Giovanni is making, and the one Kermit is making. However, I think that if we are very precise (which we're going to have to be in XDI RDF), they actually illustrated why $is is reflexive.
- >
- > I'll try to quickly explain what I mean while providing the caveat that this may be going to be hard to discuss in email, and thus I suggest we take it up further on tomorrow's telecon (to which I'll add it to the agenda, coming out next).
- >
- > I'm going to assume that Kermit's example of using the predicate "http://english.com/is" is a clever way of saying, "the predicate known in English language as the word 'is'". (If I was wrong about that, Kermit, let me know).
- >
- > If so, then in "English pseudo-X3", you could say what Kermit was expressing as:
- >
- > The number of hours in a day
- > is
- > 24.
- > The number of beers in a case
- > is
- > 24.
- >
- > If so, the inverse of both these statements would appear to be valid:
- >
- > 24
- > is
- > the number of hours in a day.
- > 24
- > is
- > the number of beers in a case.
- >
- > Also, the reflexive properties of "is" would seem to hold across any combination of the subjects and objects of these statements, i.e., you could say:
- >
- > 24
- > is
- > 24
- > The number of hours in a day
- > is
- > the number of beers in a case.
- > The number of beers in a case
- > is
- > the number of hours in a day.
- >
- > So if we agree that in all these statements the subject is a number and the object is a number -- just described in different ways -- then I think everything works. BUT if Kermit's point was that the literal "24" as a subject cannot be intrinsically determined to be a number, then I agree that there may be issues about making statements about a literal as a subject.
- >
- > Given that, here's a challenge. What about the following set of XDI statements (moving to formal X3 Whitespace for clarity):
- >
- > ["24"
- > [$is$a
- > [$literal]
- > [$type$xsd$string]
- > [$type$xsd$integer]
- > ]
- > ]
- >
- > Doesn't all that make sense? (Again, I'm not necessarily advocating for XDI subjects to allow literals. I'm just challenging the notion that there's anything logically wrong with it. The above all appears pretty intuitive to me.)
- >
- >
- > =Drummond
- >
- >
- > > -----Original Message-----
- > > From: kermit.snelson@gmail.com [ mailto:kermit.snelson@gmail.com] On Behalf
- > > Of Kermit Snelson
- > > Sent: Wednesday, March 19, 2008 12:57 PM
- > > To: Giovanni Bartolomeo
- >
- > > Cc: Drummond Reed; Markus Sabadello; barnhill_william@bah.com ;
- > > xdi@lists.oasis-open.org
- >
- > > Subject: Re: [xdi] Re: XDI subjects (was Groups - XDI RDF v8 Comments-
- > > Barnhill)
- > >
- >
- > > That's an excellent point, Giovanni.
- > >
- > > My own conclusion from your observation, however, is that the change
- > > introduced in XDI/RDF V9 that made $is reflexive and therefore
- > > eliminated $a$is as inverse was a mistake and should be repealed.
- > >
- > > The fact that RDF describes a directed graph, together with the fact
- > > that a subject is not the same thing as an object, leads me to believe
- > > that it's not meaningful to have reflexive (i.e., bidirectional)
- > > predicates in RDF.
- > >
- > > =Kermit
- > >
- > > On 3/19/08, Giovanni Bartolomeo < giovanni.bartolomeo@uniroma2.it> wrote:
- > > > Hello,
- > > >
- > > > I think I've now understood why we cannot have
- > > > XDI documents (and possibly literals) in subjects
- > > > (i.e. to have a full addressable RDF graph).
- > > > However, with predicates like $is and their
- > > > inverse (which is $is) we should proceed
- > > > carefully. Coming back to the third example by
- > > > Kermit, if we use $is as predicate we've exactly what Kermit suggested:
- > > >
- > > >
- > > > <" http://example.com/number/of/hours/in/a/day">
- > > > <" http://english.com/is"> <"24">
- > > > <" http://example.com/number/of/beers/in/a/case">
- > > > <" http://english.com/is"> <"24">
- > > >
- > > >
- > > > <"24"> <"http://english.com/is ">
- > > > <" http://example.com/number/of/hours/in/a/day">
- > > > <"24"> <"http://english.com/is ">
- > > > <" http://example.com/number/of/beers/in/a/case">
- > > >
- > > >
- > > > This is implicit in $is which MUST be symmetric
- > > > ($is inverse predicate is $is). Otherwise, I
- > > > think, the semantics of $is is lost. But probably
- > > > here $is is not the best predicate...
- > > >
- > > > Giovanni
- > > >
- > > >
- > > > At 20.57 18/03/2008, Kermit Snelson wrote:
- > > > >There are at least three reasons, in my opinion,
- > > > >why XDI/RDF subjects can't be literals: 1) RDF
- > > > >itself doesn't allow literals as subjects:
- > > > > http://www.w3.org/TR/rdf-concepts/#dfn-subject
- > > > >2) The proper XDI mapping of: Blah blah <a
- > > > >href="" http://example.com/some/target">some
- > > > >literal text here</a> blah blah would be: XDI
- > > > >subject = " http://example.com/some/target" XDI
- > > > >predicate = $html$a XDI object = "some literal
- > > > >text here" and the corresponding inline X3, with
- > > > >the additional predicates in Drummond's example,
- > > > >would be something like: Blah blah
- > > > >[ http://example.com/some/target[$html$a["some
- > > > >literal text here"]]
- > > >
- > > >[$uri$https[ https://example.com/resolvable/uri]][$is[@!F83.62B1.44F.2813!
- > > 1234]]
- > > > >blah blah 3) Allowing literals as subjects
- > > > >doesn't make logical sense. Consider the
- > > > >following:
- > > > ><" http://example.com/number/of/hours/in/a/day">
- > > > >< http://english.com/is">
- > > > ><"24">.
- > > > ><" http://example.com/number/of/beers/in/a/case">
- > > > >< http://english.com/is"> <"24">. So far, so
- > > > >good. But to assert the following: <"24">
- > > > ><"http://english.com/is ">
- > > > ><" http://example.com/number/of/hours/in/a/day">.
- > > > ><"24"> <"http://english.com/is ">
- > > > ><" http://example.com/number/of/beers/in/a/case">.
- > > > > is to assert some substantial connection
- > > > >between the number of hours in a day and the
- > > > >number of beers in a case, which is fallacious.
- > > > >=Kermit On 3/18/08, Drummond Reed
- > > > >< drummond.reed@cordance.net> wrote: > > > > >
- > > > >First, let me be clear: I'm not a big fan of
- > > > >using literals as subjects, and > I don't have
- > > > >any compelling use cases for it (see below for
- > > > >the only one > I've been thinking about). It was
- > > > >Giovanni who seemed to have a reason for > using
- > > > >literals as subjects. > > > > Second, I agree, a
- > > > >literal as a subject can't be changed or it
- > > > >becomes a new > subject from an XDI
- > > > >standpoint. > > > > Now, here's the one thing
- > > > >that's had me thinking about
- > > > >literals-as-subjects > for a long time take a
- > > > >standard HTML link
- > > > >tag: > > > > Blah blah <a >
- > > > >href="" http://example.com/some/target">some
- > > > >literal text > here</a> blah blah > > > > If you
- > > > >wanted to turn this into an XDI statement, the
- > > > >only logical mapping > that seems to make sense
- > > > >is: > > > > XDI subject = "some
- > > > >literal text here" > > XDI predicate
- > > > >= $uri > > XDI object =
- > > > >" http://example.com/some/target" > > > > In
- > > > >other words, were you to replace HTML <a> tags
- > > > >with X3 within an HTML > document, the above
- > > > >link would look like: > > > > Blah
- > > > >blah ["some literal text >
- > > > >here"[$uri[" http://example.com/some/target"]]]
- > > > >blah blah > > > > That's pretty cool, because
- > > > >now you have a way of embedding really rich >
- > > > >semantics into ordinary web pages and web links.
- > > > >As a simple example, image > being able to make
- > > > >the above simple link into a compound statement,
- > > > >which > includes: a) an alternate HTTPS URL for
- > > > >the target resource, and b) a > persistent XRI
- > > > >synonym for the
- > > > >resource: > > > > Blah blah ["some
- > > > >literal text >
- > > > >here"[$uri[" http://example.com/some/target"]] >
- > > >
- > > >[$uri$https[" https://example.com/some/target"]][$is[@!F83.62B1.44F.2813!1
- > > 234]]
- > > > > > blah blah > > > > Net net: it's the ability
- > > > >to put XDI statements inline in ordinary HTML
- > > > >and > other markup formats that's the strongest
- > > > >use case I've seen so far for > being able to
- > > > >treat literals as XDI subjects. > > > >
- > > > >=Drummond > > > > > > >
- > > > >________________________________ > > > From:
- > > > > markus.sabadello@gmail.com
- > > > >[ mailto:markus.sabadello@gmail.com] On > Behalf
- > > > >Of Markus Sabadello > Sent: Tuesday, March 18,
- > > > >2008 9:30 AM > To: Drummond Reed > Cc:
- > > > >Giovanni Bartolomeo; barnhill_william@bah.com ;
- > > > >xdi@lists.oasis-open.org > Subject: [xdi] Re:
- > > > >XDI subjects (was Groups - XDI RDF v8
- > > > >Comments-Barnhill) > > > > > > One aspect that
- > > > >seems strange with using literals as subjects is
- > > > >that you > can't modify them with XDI messages
- > > > >(I think). > > If you
- > > > >have > > =drummond > +name >
- > > > >"Drummond" > > You can modify the literal like
- > > > >this: > > =drummond > $mod > / >
- > > > > =drummond > +name >
- > > > > "D.Reed" > > But you can't modify a
- > > > >subject. > > What again was a use case for
- > > > >literals in subjects? (I'm not against it, >
- > > > >just asking) > > Markus > > > On Mon, Mar 17,
- > > > >2008 at 7:34 PM, Drummond Reed
- > > > >< drummond.reed@cordance.net> > wrote: > > > >
- > > > >[renaming this thread to something more
- > > > >relevant] > > > > Giovanni, > > > > I agree with
- > > >
- > > > >Markus I can't make sensee of having an XDI
- > > >
- > > > >document as an XDI > subject. I'm not sure my