Re: XML-Data (mapping object-style XML to frames)

On Tue, 2010-09-07 at 22:11 +0100, Dave Reynolds wrote:
> On Tue, 2010-09-07 at 16:51 -0400, Sandro Hawke wrote: 
> > Eric Prud'hommeaux and I just spent some time talking through the
> > issues, and we settled on the following design, for your consideration.
> > I kept this in the form he and I discussed; I hope the relationship to
> > rule form is clear enough.   (Eric says Hi.)
> > 
> > The XML document (no default namespace):
> >         
> >         <Person tel="x531" 
> >                 x:bday="Tuesday"
> >                 xmlns:x="http://example.org/2">
> >           <name>Eric</name>
> >           <x:bday>1966-11-08</x:bday>
> >         </Person>
> >         
> > maps to:
> >         
> >            _#<http://www.w3.org/ns/none#Person>[
> >                <http://www.w3.org/ns/none#tel> -> "x531"
> >                <http://example.org/2bday> -> "Tuesday"
> >                <http://www.w3.org/ns/none#name> -> "Eric"
> >                <http://example.org/2bday> -> "1966-11-08"
> >            ]
> >         
> > and with a default namespace:
> >         
> >         <Person tel="x531" 
> >                 x:bday="Tuesday"
> >          xmlns="http://example.org/1"
> >                 xmlns:x="http://example.org/2">
> >           <name>Eric</name>
> >           <x:bday>1966-11-08</x:bday>
> >         </Person>
> >         
> > it maps to:
> >         
> >            _#<http://example/1Person>[
> >                <http://example/1tel> -> "x531"
> >                <http://example.org/2bday> -> "Tuesday"
> >                <http://example/1name> -> "Eric"
> >                <http://example.org/2bday> -> "1966-11-08"
> >            ]
> >         
> > Several notes:
> > 
> > 1. Attribute and elements are mapped to IRIs in the same
> >    way, so you can't distinguish between them.  We suggest
> >    there are very few practical cases where you need to
> >    distinguish.  (And things are much nicer this way.)
> >    (If you need to translate to some construct (eg in jrules) that
> >    does distinguish, you can turn it into an OR of the two
> >    forms.)
> 
> Is there any evidence this is not a practical issue?
> 
> I thought XML folk were quite concerned about attribute/element
> distinction.  Certainly one use case for XML-data in RIF is to be able
> do "lift" of XML to RDF using rules and the existing XML->RDF lift
> systems I known take some care to avoid overloading element/attribute
> namespaces.

I understood this spec to be addressing OO-style XML, and as such it is
not trying to preserve (nearly) all the infoset.   Most remarkably, it
seems (on a very cursory inspection) to not care about the order of the
children.  I expect that's a fine simplification for some user
community, and I'm guessing that where that simplification is okay,
these other distinctions can also be safely lost.

But I don't know the actual use cases here at all; it seems to me this
is being driven by Christian's use cases, which I don't know.

I'm motivated by the idea of making it simple enough that I wouldn't
mind using it, for those XML cases where it applies.   I expect for the
rest of XML to use something that explicitly covers the whole infoset.

     -- Sandro




> Dave
> 
> > 
> > 2. The IRI is constructed by simply concatenating the namespace and
> >    the local part of the name, so you get the slightly odd looking
> >    http://example.org/2bday and http://example/1tel.  Since people
> >    wont usually see these, it should not be a problem.
> > 
> > 3. Attributes with no namespace are treated as if they had the
> >    namespace of their element.  (Again, we lose some ability to
> >    distinguish between certainl XML documents, but it should be fine.)
> > 
> > 4. Elements with no namespace are treated as if they had the namespace
> >    "http://www.w3.org/ns/none#".
> > 
> > This seems to us to be pretty easy to use, about the same implementation
> > difficulty, and only excluding a few XML documents that would otherwise
> > be processable.   (You were already excluding the ones where order
> > matter, right?  If not, we'd need to bring in lists.)
> > 
> >       -- Sandro
> > 
> > 
> 
> 
>

Received on Tuesday, 7 September 2010 21:36:04 UTC