Re: Literals as subjects in Turtle (but not in the RDF model) [was: Inverses of RDF and RDFS predicates]

Drat.  Here I was, first trying to make lemonade from lemons, then
trying to exchange the lemons for plums, and I get tomatoes thrown back
both ways.  ;)

I guess the only real solution is adopt a charter that allows this
glitch to be fixed properly, in the RDF model.

David

On Thu, 2012-05-03 at 19:01 +0200, Ivan Herman wrote:
> David,
> 
> (As the others, my reaction is personal. Not an official WG or W3C
> position...)
> 
> Just to react on the literal as subject in turtle issue: I would be
> very much opposed to this. We already have a major issue in the Web
> community at large to convey the difference between RDF  as a model,
> and the syntax expressing it. This confusion backfired big time in the
> past. Creating an RDF serialization that would allow more than what
> the RDF model allows would add to the confusion. Big time.
> 
> Sorry...
> 
> Ivan
> 
> 
> 
> ---
> Ivan Herman
> Tel:+31 641044153
> http://www.ivan-herman.net
> 
> (Written on mobile, sorry for brevity and misspellings...)
> 
> 
> 
> On 3 May 2012, at 17:53, David Booth <david@dbooth.org> wrote:
> 
> > Hi David & Richard,
> > 
> > I like the line of thinking that you suggest, and I agree with the
> > practical arguments that you make (about not materializing inverse
> > triples and not maintaining extra vocabulary), but there is currently an
> > asymmetry in the RDF language that makes this not quite work in the
> > general case, though it can work in many specific cases.  
> > 
> > In essence, you are suggesting that there is no difference between an
> > inverse predicate and the expression of that predicate in the opposite
> > direction of the triple, and therefore the inverse predicate is
> > unnecessary, because it is redundant.  In other words, if IP is the
> > inverse of predicate P, then for any X and Y, if I want to express the
> > following fact in RDF
> > 
> >  X IP Y .
> > 
> > but without using the predicate IP, then instead I can merely represent
> > that fact in RDF as
> > 
> >  Y P X .
> > 
> > and the exact same information is captured.
> > 
> > I think this is a great way to look at it.  (And I advocated this line
> > of thinking at the RDF Next Steps workshop two years ago.)  But the
> > glitch is that for this to always work, RDF must allow literals in the
> > subject position, and it doesn't.  Furthermore, the RDF WG charter does
> > not allow this glitch to be fixed in the RDF model:
> > http://www.w3.org/2011/01/rdf-wg-charter
> > "3. Out of Scope.  Some features are explicitly out of scope for the
> > Working Group . . . Removing current restrictions in the RDF model
> > (e.g., literals not allowed as subjects, or blank nodes as predicates)"
> > 
> > On the other hand, just to toss an idea out there . . . even if the
> > charter does not allow this to be fixed in the RDF *model*, how about at
> > least fixing it in the Turtle *syntax*?  The following two, simple
> > changes to the Turtle grammar would make it easy to express any triple
> > in the inverse direction.  First, allow literals as subjects:
> > 
> > [10]   subject   ::=   IRIref
> >                       | blank
> >                       | literal
> > 
> > Second, allow a predicate to be written in the inverse direction:
> > 
> > [11]   predicate ::=   IRIref
> >                       | "^" IRIref
> > 
> > Granted, these changes would make it possible to write some things in
> > Turtle syntax that would not be valid RDF.  (Hmm ... would that be the
> > case anyway?)  So if one wanted to be certain that some Turtle is valid
> > RDF, one would have to run it through an RDF validator.
> > 
> > RDF/XML could still merrily reject literals as subjects.   
> > 
> > Tools that people do not want to update could still (rightfully) reject
> > RDF that had literals as subjects, while those of us who would rather
> > live without this restriction could use tools that allow them.  Freedom
> > of choice!  Rah rah rah!  :)
> > 
> > One could argue that this would represent an end run around the intent
> > of the charter.  But I personally find the restriction against literals
> > as subjects so silly and onerous that I think this approach could
> > represent a reasonable balance between those who don't want to modify
> > old tools and those who don't want this restriction.
> > 
> > Comments?
> > 
> > David
> > 
> > 
> > On Thu, 2012-05-03 at 07:27 -0400, David Wood wrote:
> >> Hi David,
> >> 
> >> This is also a personal response, since the WG has not yet discussed
> >> the issue.
> >> 
> >> We have implemented support for reverse link traversal in Callimachus
> >> specifically to avoid the need for materializing additional triples.
> >> Other systems have similar functionality.  Thus, I am in agreement
> >> with Richard that the *standardization* of inverse predicates may be
> >> detrimental in that it may constitute an encouragement for
> >> materialization over other traversal mechanisms.  In my opinion, those
> >> mechanisms are best left to implementors.
> >> 
> >> Regards,
> >> Dave
> >> 
> >> 
> >> 
> >> 
> >> On May 3, 2012, at 07:05, Richard Cyganiak wrote:
> >> 
> >>> Hi David,
> >>> 
> >>> (This is a personal response, not necessarily representing WG opinion.)
> >>> 
> >>> I think that introducing inverse properties would be a bad idea
> >> here, because it leads to an unnecessary proliferation of redundant
> >> vocabulary terms and makes querying and generally working with the
> >> data much harder.
> >>> 
> >>> Avoiding “incoming” arcs to an RDF node, and wanting only having
> >> “outgoing” arcs, is a common reflex in the community. This is very
> >> unfortunate IMO. Both kinds of arcs are equally important and
> >> essential. We need *graphs* not trees.
> >>> 
> >>> I'm not convinced by the reasons you state for introducing inverses.
> >> See below.
> >>> 
> >>> On 30 Apr 2012, at 15:40, David Booth wrote:
> >>>> 1. It allows one to conveniently distinguish those statements from other
> >>>> statements in which :C appears in the object position of the triple.
> >>>> This is what is done in computing the Concise Bounded Description:
> >>>> http://www.w3.org/Submission/CBD/
> >>> 
> >>> The answer is right in this document: Symmetric CBDs.
> >>> 
> >>>> It is a common approach taken for DESCRIBE queries in SPARQL.
> >>> 
> >>> Generally the DESCRIBE behaviour can be configured in the RDF store
> >> to SCBDs.
> >>> 
> >>>> One could reasonably argue that instead you should put those statements
> >>>> in a separate graph if you wish to distinguish them from statements in
> >>>> which :C appears as in the object position of the triple.  Indeed, one
> >>>> could, but that adds complexity.  And the fact is, it is convenient to
> >>>> be able to do it this way.
> >>> 
> >>> Why would you want to put them into a different graph? Just put them into the same graph.
> >>> 
> >>>> 2. It allows one to use certain optimizations that are asymmetric.  In
> >>>> particular, if I represent my RDF triples using a hash table for each
> >>>> subject, then I can very quickly and easily lookup the members of
> >>>> class :C by using rdf:isTypeOf as the hash table index.  
> >>> 
> >>> Use two hash tables, one for incoming and one for outgoing triples. Now you can represent nodes in a graph, rather than just nodes in a tree.
> >>> 
> >>>> In essence, the ability to use the inverse property gives the author
> >>>> more flexibility in writing RDF.  
> >>> 
> >>> It gives flexibility for RDF authors, but creates headaches for users of the data, and asks vocabulary maintainers to do lots of redundant extra work.
> >>> 
> >>> All the best,
> >>> Richard
> >>> 
> >>> 
> >>> 
> >>> 
> >>>> This can be helpful both as a
> >>>> convenience for the author and to simplify downstream code that
> >>>> processes that RDF.
> >>>> 
> >>>> Let me know if further clarification would help.
> >>>> 
> >>>> Thanks!
> >>>> David
> >>>> 
> >>>> On Mon, 2012-04-30 at 08:20 -0400, David Wood wrote:
> >>>>> Hi David,
> >>>>> 
> >>>>> Can you please articulate one or more use cases to accompany this
> >>>>> feature request?  Thanks.
> >>>>> 
> >>>>> Regards,
> >>>>> Dave
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> On Apr 29, 2012, at 19:43, David Booth wrote:
> >>>>> 
> >>>>>> If this has already been considered and rejected by the WG then please
> >>>>>> ignore, but . . . 
> >>>>>> 
> >>>>>> It would be helpful if the RDF and RDFS specs defined inverses for the
> >>>>>> properties that they define.  For example, if
> >>>>>> 
> >>>>>> :x  rdf:type  :C .
> >>>>>> 
> >>>>>> then one might write:
> >>>>>> 
> >>>>>> :C rdf:isTypeOf :x .
> >>>>>> 
> >>>>>> and similarly for other properties.
> >>>>>> 
> >>>>>> I have resorted to defining my own inverse properties for some of these,
> >>>>>> but it seems silly to do so, rather than standardizing them, especially
> >>>>>> since it wouldn't add anything significant to the semantics.
> >>>>>> 
> >>>>>> 
> >>>>>> -- 
> >>>>>> David Booth, Ph.D.
> >>>>>> http://dbooth.org/
> >>>>>> 
> >>>>>> Opinions expressed herein are those of the author and do not necessarily
> >>>>>> reflect those of his employer.
> >>>>>> 
> >>>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>> 
> >>>> -- 
> >>>> David Booth, Ph.D.
> >>>> http://dbooth.org/
> >>>> 
> >>>> Opinions expressed herein are those of the author and do not necessarily
> >>>> reflect those of his employer.
> >>>> 
> >>>> 
> >>> 
> >> 
> >> 
> >> 
> > 
> > -- 
> > David Booth, Ph.D.
> > http://dbooth.org/
> > 
> > Opinions expressed herein are those of the author and do not necessarily
> > reflect those of his employer.
> > 
> > 
> 
> 

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Thursday, 3 May 2012 18:05:14 UTC