Re: Well Behaved RDF - Taming Blank Nodes, etc.

Dear all

I'm 100% with Pat here in the defence of blank nodes, as ever [1]
The more I'm using RDF daily, the more I love them, and seems to me you
miss a lot of RDF expressivity by wanting everything to be uniquely
identified by a URI
Just another example : "John met a girl yesterday in a cafe".
Are you going to coin a URI for those ill-identified girl, cafe, and event?
Certainly not. But you want to record this information in John's bio
because you guess it's likely to be of some importance later in his life,
even if so far you don't know more about it.

The "natural" expression of things in RDF is that some event in the life of
John took place yesterday, involving some girl in some cafe.

@prefix bio:<http://vocab.org/bio/0.1/>
@prefix foaf:<http://xmlns.com/foaf/0.1/>
@prefix schema:<http://schema.org/>

:John    bio:event   _:someEvent .
_:someEvent  bio:Date  '2012-12-12' .
_:someEvent  bio:Participant  _:someGirl .
_:someEvent  bio:place _:someCafe .
_:someGirl  a  foaf:Person .
_:someGirl  foaf:gender  'female' .
_:someCafe  a  schema:CafeOrCoffeeShop .

I hear already objections : this is an academic example with no business
value etc.
I'm sure people working in history, science, intelligence, investigation,
(or even tabloids) ... any domain where uncomplete information dealing with
ill-identified or partially known entities has to be recorded for further
research, can come with ever more complex real-life situations.

Best

Bernard

[1] http://blog.hubjects.com/search?q=blank+node

2012/12/13 Pat Hayes <phayes@ihmc.us>

>
> On Dec 12, 2012, at 10:10 AM, Hugh Glaser wrote:
>
> > Nice idea David.
> > And I like that your example is about *consumption*, not production - I
> would hope that this exercise can use ease of consumption as the metric.
> >
> > Your example of blank nodes is very important.
> > Another problem of blank nodes is that no-one else can make statements
> about the resource.
> > I won;t get into the discussion about whether blank nodes should be
> banned :-)
> > But this argument against their use leads me to a rule of thumb:
> >
> > A string literal should only ever appear as the object of rdfs:label (or
> something that could naturally be made a sub-property of rdfs:label, such
> as foaf:name).
>
> What complete nonsense. At least there is some practical reason to
> restrict bnodes, but none whatsoever for this.
>
> > dHopefully the reason for this is clear:- if it is somewhere else, then
> it is essentially identifying a resource; and if it is a resource, someone
> else (or you, one day) may want to refer to it. And of course, if it is a
> string, you can't do that.
>
> Wherever it occurs, it is identifying a string. String literals ALWAYS
> identify strings, as a matter of logical necessity. So of course you can
> refer to it: you use the string literal. (Duh.)
>
> > Yes, I know it is an extra URI (not blank, of course!) and a triple, but
> what is the point of RDF if you can't refer to resources?
> > I have to say that whenever I have been tempted to put a string in
> somewhere else I have been able to work out very real use cases where it
> would have been a bad thing to do.
> > Strings are labels, and that's it.
> >
> > So what about other literals?
> > I actually wonder whether the same is often true here, but perhaps not
> as strongly. Should they only be used as the object of rdf:value or similar.
> > Consider if you have made a statement publishing your age using
> foaf:age. The age is an integer string.
> > This means that I can't make a comment on your age :-)
> > Or rather, if I do comment on your age, it will have to be more complex,
> and involve a URI for you.
>
> Just as the data you are commenting on does.  You seem to be saying that
> in order to comment on data, you have to use the same conventions as the
> data already uses, to refer to the things that the data refers to. A good
> point, but I don't see what it has to do with literals.
>
> > So I can't for example say that your age is the same as my age (with
> some predicate).
>
> Pat sameAgeAs Hugh .  Looks OK to me. Or if you want to do it in Owl, you
> could use a restriction class of people with the same value of the hasAge
> property as mine, and say you are in it.
>
> > And I can't give you a URI that is my age, that you could give to
> someone else who might know what it means, even though you don't.
>
> How could a URI identify my age? I will invent one that does, here goes:
> http://www.ihmc.us/groups/phayes/frongle. OK, that denotes my age. Good
> luck with finding out how old I am, though. To do that, you would probably
> have to find some RDF that said something like
>
> http://www.ihmc.us/groups/phayes  :age
> http://www.ihmc.us/groups/phayes/frongle .
> http://www.ihmc.us/groups/phayes/frongle :valueInYears "68"^^xsd:number .
>
> I fail to see how this is more useful than
>
> http://www.ihmc.us/groups/phayes foaf:age "68"^^xsd:number .
>
> and it doesn't have any fewer literals in it.
>
> Pat
>
>
> >
> > I'm not sure if this is the sort of thing you were asking for, but
> that's my 2 cents worth.
> >
> > Best
> > Hugh
> > On 12 Dec 2012, at 17:01, David Booth <david@dbooth.org>
> > 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.
> >>
> >> 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?  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 “( . . . )”?
> >> 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
>
>
>
>
>
>
>


-- 
*Bernard Vatant
*
Vocabularies & Data Engineering
Tel :  + 33 (0)9 71 48 84 59
Skype : bernard.vatant
Blog : the wheel and the hub <http://blog.hubjects.com/>

--------------------------------------------------------
*Mondeca**          **                   *
3 cité Nollez 75018 Paris, France
www.mondeca.com
Follow us on Twitter : @mondecanews <http://twitter.com/#%21/mondecanews>