W3C home > Mailing lists > Public > www-rdf-interest@w3.org > May 2002

RE: bNodes wanted

From: <tony_hammond@harcourt.com>
Date: Wed, 29 May 2002 08:00:44 +0100
To: "Seaborne, Andy" <Andy_Seaborne@hplb.hpl.hp.com>
Cc: "'Aaron Swartz'" <me@aaronsw.com>, www-rdf-interest@w3.org
Message-ID: <OF2245A986.1D608C89-ON80256BC8.0025EAF5@harcourtbrace.com>

Well this bNode debate is very promising. Our take on bNodes is to manage
resource collections. The model we have proposed - YADS - is premised on
bNodes which are used to build compound objects around a central resource
or collection property (through which a hierarchy can be propagated) - full
n3 below. A real "house of cards" model. See


for documentation and some applications (YADS schema tree, DOI multiple
resolution, XLink, RFC 2396).

The model allows for a safe and scalable solution to describing resource
collections and the simple, recursive model of hierarchy allows for a
trivial XML de/serialization of the tree.  Our interest in hierarchy is to
compartmentalize multiple collections. Interested to get any feedback. (BTW
- all the diagrams use typed bNodes.)


  @prefix  : <#> .
  @prefix s: <http://www.w3.org/2000/01/rdf-schema> .

  # Nest class ( :collection & :resource )
  :Nest a s:Class .
  # Item class ( :collection | :resource )
  :Item a s:Class .

  # Resource properties
  :collection a s:Property ;
      s:domain :Item, :Nest ; s:range s:Container .
  :resource a s:Property ;
      s:domain :Item, :Nest ; s:range s:Resource .

  # Literal properties
  :access a s:Property ;
      s:domain :Item, :Nest ; s:range s:Literal .
  :detail a s:Property ;
      s:domain :Item, :Nest ; s:range s:Literal .
  :directive a s:Property ;
      s:domain :Item, :Nest ; s:range s:Literal .
  :label a s:Property ;
      s:domain :Item, :Nest ; s:range s:Literal .
  :role a s:Property ;
      s:domain :Item, :Nest ; s:range s:Literal .
  :service a s:Property ;
      s:domain :Item, :Nest ; s:range s:Literal .
  :type a s:Property ;
      s:domain :Item, :Nest ; s:range s:Literal .

                    "Seaborne, Andy"                                                                                      
                    <Andy_Seaborne@hplb.h       To:     "'Aaron Swartz'" <me@aaronsw.com>                                 
                    pl.hp.com>                  cc:     www-rdf-interest@w3.org                                           
                    Sent by:                    Subject:     RE: bNodes wanted                                            
                    24/05/2002 11:29                                                                                      

Two cases where I use bNodes (which may be different to what they are meant

1/ the thing is not web resource (people, organisations, email messages and
that Porsche I don't have)
2/ grouping to build information about a composite concept

Abusing the ontology for ISWC:

     <homepage rdf:resource='http://www-uk.hpl.hp.com/people/afs'/>
     <name rdf:parseType="Resource">

I am not a web resource but can be found by my homepage.  My name has
structure and this could be useful to retain.

You can refer to a bNode - you find it by query.  It is especially
interesting if you find more than one.  URIs don't really have such a
priviledged place - we could have all bNodes and a property "hasURI" and
then everything is found by query.


-----Original Message-----
From: Aaron Swartz [mailto:me@aaronsw.com]
Sent: 23 May 2002 22:16
To: Seaborne, Andy
Cc: www-rdf-interest@w3.org
Subject: Re: bNodes wanted

On Thursday, May 23, 2002, at 07:36  AM, Seaborne, Andy wrote:

> A precursor to better modelling is more bNodes - and a general
> enthusiasm to
> use them.  I think people shy away from them at present which hurts data
> integration (amongst other things).

Could you elaborate? I've always found bNodes a bad idea, since, among
other things, you can't refer to them and so I strongly recommend
against them.

Aaron Swartz [http://www.aaronsw.com]
Received on Wednesday, 29 May 2002 03:18:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:36 UTC