- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Wed, 19 Dec 2012 11:36:10 -0500
- To: Henry Story <henry.story@bblfish.net>
- CC: Pat Hayes <phayes@ihmc.us>, David Booth <david@dbooth.org>, semantic-web <semantic-web@w3.org>
On 12/19/2012 10:47 AM, Henry Story wrote: > On 19 Dec 2012, at 16:42, Lee Feigenbaum <lee@thefigtrees.net> wrote: > >> On 12/19/2012 9:50 AM, Henry Story wrote: >>> On 12 Dec 2012, at 18:43, Pat Hayes <phayes@ihmc.us> wrote: >>> >>>> On Dec 12, 2012, at 9:01 AM, David Booth wrote: >>>> >>>>> I'm writing a paper to propose a profile of RDF that would enable >>>>> simpler tools to process RDF, and I'm wondering if others have >>>>> suggestions of constraints that may be helpful to include. The idea is >>>>> not to change the RDF standard, but to define a useful, voluntary subset >>>>> -- Well Behaved RDF -- that is sufficient for most RDF applications but >>>>> simplifies their development. >>>>> >>>>> For example, one key limitation would be in the use of blank nodes, >>>>> which severely complicate what could otherwise be simple tasks, such as >>>>> comparing two RDF graphs for equality. With unrestricted blank nodes, >>>>> this becomes a difficult graph isomorphism problem instead of a simple >>>>> text comparison. Some have suggested eliminating blank nodes entirely, >>>>> but a more modest restriction would be to limit them to common idioms >>>>> that do not cause such complexity problems: >>>>> >>>>> A Well-Behaved RDF graph is an RDF graph that can be serialized >>>>> as Turtle without the use of explicit blank node identifiers. >>>>> I.e., only blank nodes that are implicitly created by the >>>>> bracket "[ ... ]" or list "( ... )" notations are permitted. >>>> That is too restrictive. There is a real need to be able to describe things such as "Joe's father" or "a woman in a red dress" which are naturally phrased as bnodes with identifying descriptors attached to them. >>> Yes, but here for a HTTP related example: >>> >>> The web creates such resources all the time: whenever you POST a form >>> and the server does not give you a URI for the returned result, you have in >>> fact created a resource that has not got a name. This resource will need to be >>> described using a blank node. It could be described well enough as a creation of >>> that form, and with date and time, but giving it a name on that server would be >>> an error, and forcing oneself to name a remote resource, when the remote owner >>> did not want to do that is more work than you may want. >> What's wrong with generating a UUID-based URI for a POST request? > There's nothing wrong per se. But it is more prone to a mistake happening > that having a blank node. The blank node is the easiest way to deal with > things that don't have names. What sort of mistakes do you have in mind with URIs? With blank nodes, the mistakes are well-understood (see the modelling mistakes elsewhere in this thread and also the common mistake of attempting/expecting to reuse blank node identifiers). > > Here's another example: Imagine you have a rdf store and your URI index breaks. > You may have a bunch of things you can say about those URIs such as the > domain name and the protocol, but not the full path. There again it would be > easiest to describe this with blank nodes. I must admit to not understanding the scenario you're describing here. Generally speaking, I'm not very motivated by design decisions based on buggy pieces of software, but likely I'm misunderstanding. > > In any otherwise you end up with names that are just complicated blank nodes, and you > then have exactly the same problem as blank nodes, except you just end up growning and > growing your names as you go along. Well, except they don't have the same problems as blank nodes: UUID URIs are stable from one query to the next and can be linked to and referenced across document/database-context. > > But this is another http-range-14 like debate I think. I'd better not get involved.... Your choice; as I said, I don't feel religious on this topic, but I'm trying to understand "the other side" and see what's general feeling versus concrete issues. I'm also trying to learn for my own nefarious purposes: to understand clearly when I'd want to use blank nodes. Lee > >> Lee >> >>>>> Are there other restrictions that would be helpful to have in a Well >>>>> Behaved RDF profile, which would simplify our lives as RDF developers, >>>>> but still meet the needs of most RDF applications? For example, what if >>>>> anything might be said about non-lean RDF graphs? Should typed literals >>>>> be required to be well formed per their type semantics? >>>> FWIW, the RDF2 WG may well decide to make graphs with illformed literals inconsistent, which is equivalent to saying that the type semantics is imposed by the simple use of the literal. >>> I hope that does not make it impossible to create new literals. >>> >>>>> Should the use >>>>> of rdf:first and rdf:rest be limited to well-formed, rdf:nil-terminated >>>>> lists, i.e., those that can be serialized as Turtle lists “( . . . )”? >>>> That makes perfect sense. The 2004 specs suggest this, in fact: they permit applications to treat 'silly' list descriptions as errors. >>>> >>>> Pat >>>> >>>> >>>>> Etc. What do others think? >>>>> >>>>> >>>>> -- >>>>> David Booth, Ph.D. >>>>> http://dbooth.org/ >>>>> >>>>> Opinions expressed herein are those of the author and do not necessarily >>>>> reflect those of his employer. >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------ >>>> IHMC (850)434 8903 or (650)494 3973 >>>> 40 South Alcaniz St. (850)202 4416 office >>>> Pensacola (850)202 4440 fax >>>> FL 32502 (850)291 0667 mobile >>>> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes >>>> >>>> >>>> >>>> >>>> >>>> >>> A short message from my sponsors: Vive la France! >>> Social Web Architect >>> http://bblfish.net/ >>> > A short message from my sponsors: Vive la France! > Social Web Architect > http://bblfish.net/ >
Received on Wednesday, 19 December 2012 16:36:36 UTC