W3C home > Mailing lists > Public > www-rdf-comments@w3.org > January to March 2001

Re: regarding rdfms-identity-anon-resources

From: Gabe Beged-Dov <begeddov@jfinity.com>
Date: Sat, 10 Mar 2001 10:39:34 -0800
Message-ID: <3AAA74E6.969CC930@jfinity.com>
To: Jonathan Borden <jborden@mediaone.net>
CC: Brian McBride <bwm@hplb.hpl.hp.com>, www-rdf-comments@w3.org
IMHO, you are conflating XML fragment identification with anon
resource identification. There are many ways to signal via a fragment
identifier that a particular URIref is a special resource. Using
XPointer child sequence is an interesting one but is indirect and
requires that these kinds of syntactic shorthands be only used for
anon resource labeling. 

If you go down this path, I think you might as well use an explicit
fragment scheme like x-anon or something else. This also doesn't
address round tripping. I.e. how do you regenerate an XML document
where the XPointer shorthand (which isn't a valid XML Name it seems)
is valid?

Gabe

Jonathan Borden wrote:
> 
> Brian McBride wrote:
> >
> >
> > Jonathan,
> >
> > I'm not sure exactly what it is you are suggesting.  Can you provide
> > some
> > concrete examples of the application of this suggestion, outlining the
> > benefits that it brings.
> >
> > I have some more abstract questions that I'm wary of as abstract
> > discussions
> > on this topic don't always seem to clarify my understanding.  However,
> > they might give you some idea of what it is I'm not understanding.
> 
> In general my position is that the issues of naming and addressing often get
> conflated when assigning a URI to a 'resource'.
> 
> I am going to resist the temptation to answer these questions because I've
> seen these abstract discussions go round and round without apparent
> resolution. In general whether something is abstract or concrete,
> theoretical or physical depends on how you look at it and is ultimately a
> matter of local convention.
> 
> Let's start with these definitions and see how far we get:
> 
> When parsing an XML document, for the moment an XML document that conforms
> to the RDF syntax, a series of triples (p,s,o) are emitted. This set of
> triples is incorporated into an RDF model, or abstract syntax. For each
> (p,s,o) the RDF M&S 1.0 recommendation specifies a set of rules for
> generating URI references from the document being parsed.
> 
> It may occur that the syntax provides no explicit 'name' for a resource.
> Such a resource is termed 'anonymous'. The parser must assign a name to the
> resource for the purpose of generating a URI ('Skolemize'). Such functions
> e.g. generate-id() produce names such as: "genid12345".
> 
> It has been pointed out (TimBL) that such naming of anonymous resources has
> problems.
> 
> I propose that instead of 'naming' such anonymous resources, the resource
> can be addressed by its position in the originating document hence producing
> a URI reference that is an address but not a proper name.
> 
> The XPointer 'child sequence' syntax provides such addresses _with the
> benefit that syntax of these addresses does not clash with the symbol space
> of proper names_ i.e. a child sequence is of the form:
> 
> /1/2/3/4 and this can _always_ be disambiguated from an XPointer 'raw name'
> such as might be produced by an rdf:ID label (actually only if rdf:ID were a
> proper ID).
> 
> Examples:
> 
>         A name: "Fred Jones"
>         An address of an anonymous person "The man third from the left in the first
> row of the photo"
> 
> <person rdf:ID="ABC123" rdf:parseType="Resource">
>         <person.name>
>                 <first>John</first>
>                 <last>Doe</last>
>         <person.name>
>         <ssn>12345</ssn>
> </person>
> 
> the node corresponding to the element "person.name" will be 'anonymous'. It
> can be referred to with the child seq:
> 
> /1/2
> 
> it can also be referred to using the xpath
> 
> person[@rdf:ID='ABC123']/person.name
> 
> which combines a name and an address but the child seq form is a 'pure'
> address.
> 
> >
> >   o does this suggestion work when the variable is represented in N3 and
> >     there is no XML representation for it?
> 
> A proper ENBF syntax or property set for N3 would enable an addressing
> scheme for N3 documents. To my knowledge no such addressing syntax has been
> defined for N3 as yet (one can always punt and refer to the 'statement
> beginning at character 45 in the document', third statement in the document
> etc. choose. )
> 
> >
> >   o are you suggesting that any resource identified by an XPointer is an
> >     anonymous resource?
> 
> no. XPointer defines several forms:
> 
> raw name: this directly corresponds to an ID and is hence a name
> child sequence: this is an address
> combined raw name/child sequence
> full xpointer
> 
> what I am saying is that a child sequence -- which is identified by the
> starting '/' _is_ always an address and hence corresponds to an anonymous
> resource. One can identify a URI as denoting an anonymous resource by
> detecting a '/' immediately following the '#' -- i.e. in the first character
> of the fragment identifier. This is not to say that _only_ child seqs
> identify anonymous resources.
> 
> >
> > Brian
> >
> >
> > Jonathan Borden wrote:
> > >
> > > Regarding anon resources. At the RDF IG F2F I made the point
> > that one can
> > > use XPointers to identify 'anonymous' resources using three forms (of
> > > XPointer)
> > >
> > > 1) raw name - ID
> > > 2) child sequence e.g. /1/2/3
> > > 3) full xpointer e.g. #xpointer(//xxx:foo[@name='bar'])
> > >
> > > TimBL noted that it is useful to know when a resource is anonymous. I
> > > pointed out that assuming child seqs or full xpointers are used that the
> > > lexical space of a URI reference naming anonymous resource is
> > distinct (e.g.
> > > test for '/' or 'xpointer(' immediately following '#'. Hence it will be
> > > known that the URI is an 'address' not a 'name'.
> > >
> 
> Jonathan Borden
> The Open Healthcare Group
> http://www.openhealth.org
> >

-- 
--------------------------- 
http://www.jfinity.com/gabe
Received on Saturday, 10 March 2001 12:42:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 September 2012 14:16:27 GMT