- From: Nathan <nathan@webr3.org>
- Date: Thu, 03 May 2012 22:48:58 +0100
- To: Sandro Hawke <sandro@w3.org>
- CC: David Booth <david@dbooth.org>, Ivan Herman <ivan@w3.org>, David Wood <david@3roundstones.com>, Richard Cyganiak <richard@cyganiak.de>, "public-rdf-comments@w3.org" <public-rdf-comments@w3.org>
Sandro Hawke wrote: > Glad to see a message from you, Nathan. I hope you're well! Thanks, and yes I'm "okay" probably quiet for the remainder of this year but hoping to be back and doing things from the end of the year for the foreseeable future ... > On Thu, 2012-05-03 at 19:59 +0100, Nathan wrote: >> This all seems very circular, self perpetuating, and arbitrary. >> >> The reason "literal as subjects" do not appear in the serializations is >> because they are not handled in the model. The reason they are not >> handled in the model is because they do not appear in the >> serializations. Thus, circular. >> >> Given a random property y and it's inverse x, then what factors are >> considered when deciding which of x & y to choose as the "primary" >> property, which becomes named and documented by it's creator. Well if >> the domain of y is literal then defining that property is pretty much a >> wasted effort since both the RDF model and serializations won't cater >> for it, thus the property creator will choose to name and document x >> with a range of literal. Thus, self perpetuating. >> >> When working with RDF computationally, or doing any reasoning and >> inference, the code one creates has to handle, at some point, literal >> subjects - > > What I understood several people to say at the RDF Next Steps Workshop, > and on the mailing lists after it, was that their RDF systems were not > like this. They said their systems could not handle literals in the > subject position without a more re-working than they were willing to do. > They claimed it was not a simple matter of removing a restriction. As I > recall, these were some of the major RDF product suppliers and/or users, > so it seemed to make sense to listen. > > I suspect the difference here is that they don't do much inference. I > think you're right that systems which do inference (past a certain level > of expressiveness) must handle literals as subjects, but it turns out > that right now a large portion of the RDF community doesn't do that. > And the folks that do that kind of inference *can* work around the > restrictions. > > If not for all this, yes, I think your argument (and the arguments many > of us have made) would be compelling. Yes, I have to agree, and it's part of the reason why I took a back step, I realise me banging on about these kind of things doesn't do anybody any favours, and the only thing that really would make a difference is to throw in a huge amount of time to N3, RIF, "RDFS 3.0", Tabulator and the stuff DIG/CSAIL are working on, related logics (Pat's work) and try to converge that with what's needed for the RWW of Linked Data and emerging web apps - that's quite a mammoth task and probably not quite as time sensitive as I first thought it to be. Ultimately, there are a lot of skilled and hard working people in the sem web, and RDF WG, so I'm quite sure what is produced will certainly work for a big chunk of important tasks. Additionally, it perhaps isn't wise to throw everybody in to heavy reasoning and inference until the web science and philoweb people have had a good chance to understand the privacy and security concerns it will raise (as Tim outlined in his recent www2012 keynote.) Best & kutgw, Nathan >> this is because as we all know RDF is a graph, not a tree. >> Adding a constraint that one node in that graph can only be >> (un)named-node whilst another can be of any type is entirely arbitrary >> and not reflected by the core mathematics or the shape of the world. >> This is why why Tim & Dan created N3 they naturally allowed literal >> subjects, and similarly why you'll find them in LBase from pat, and why >> you'll find them in the depths of pretty much all our code. Arbitrary. >> >> This is confusing, leads to unexpected functionality, arbitrarily limits >> unexpected reuse, makes the model/semantics more complex than they need >> to be, leads to inconsistencies which rear their heads often, and >> something to which not one sound technical or moral argument been seen. >> >> I'll duck back out now as I've wasted enough of everybody time over the >> years on this issue, and it certainly isn't going to change. >> >> Best, >> >> Nathan >> >> David Booth wrote: >>> 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. >>>>> >>>>> >> >> > > > > >
Received on Thursday, 3 May 2012 21:49:48 UTC