- From: Phil Dawes <pdawes@users.sf.net>
- Date: Fri, 14 Jan 2005 15:59:04 +0000
- To: Ian Davis <iand@internetalchemy.org>
- Cc: atom-owl@googlegroups.com, jsled@asynchronous.org, www-rdf-interest@w3.org, bloged <users@bloged.dev.java.net>
Hi Ian, I originally put 'rdf:type' transformations into my xml2rdf proof-of-concept script, but found them unnecessary after reading Henry's post. By translating all the tags into properties, you simplify the transformation, and allow for rdfs schemas to fill in the type info. (An rdf tax only necessary for those handling RDF) E.g. the mapping for > 1. Element is empty. > > <item> > <ex:extension/> > </item> [] atom:item _:item . _:item ex:extension _:ext . But there could be an rdfs written by rdf folks saying: atom:item rdfs:range atom:Item. (therefore adding the _:item a atom:Item. inference for RDF users) Cheers, Phil Ian Davis writes: > > On 14/01/2005 12:51, Henry Story wrote: > > > > Thanks Josh, > > > > I like your answers to Ian's questions :-) > Me too :) > > > > I don't think any heuristics are needed. Just an ontology for the > > tags and attributes plus a systematic way to map xml into graph space > > which I have described in this thread. > > The point I was attempting to get across in my original email was that I > could think of no heuristic that would give a consistent mapping using > only the instance document. The mappings that Josh came up with aren't > consistent: I would need to use a different query against the triple > store for each form to extract the content (for display, perhaps). > > With some kind of schema annotation one could declare that the content > of <extension> is always an XMLLiteral. > > For the format that provoked this discussion (Atom) it's expected that > authors will extend the format in new and exciting ways. Giving the > parser knowledge of all possible extensions up front in the form of a > schema for each is rather defeating the point of the mapping. > > So, there need to be some sort of structural rules that define what > types of triples should be produced. These rules should be consistent > and work from the instance document. For the specific case of Atom the > following suggested equivilences between markup and NTriples might serve: > > 1. Element is empty. > > <item> > <ex:extension/> > </item> > > _:item a atom:item . > _:item ex:extension _:ext . > > 2. Element is empty, but has attributes -> Attributes are assumed to be > properties. > > <item> > <ex:extension ex:att="xxx"/> > </item> > > _:item a atom:item . > _:item ex:extension _:ext . > _:ext ex:att "xxx" . > > > 3. Element has character content -> Content becomes rdf:value of anon node > > <item> > <ex:extension>xxx</ex:extension> > </item> > > _:item a atom:item . > _:item ex:extension _:ext . > _:ext rdf:value "xxx" . > > 4. Element has mixed content -> Content becomes rdf:value as above > > <item> > <ex:extension>xxx<other/></ex:extension> > </item> > > _:item a atom:item . > _:item ex:extension _:ext . > _:ext rdf:value "xxx<other/>" . > > 5. Element has element content -> Content still becomes rdf:value as above > > <item> > <ex:extension><other/></ex:extension> > </item> > > _:item a atom:item . > _:item ex:extension _:ext . > _:ext rdf:value "<other/>" . > > 6. Element has content and attributes. > > <item> > <ex:extension ex:att="xxx">xxx<other/></ex:extension> > </item> > > _:item a atom:item . > _:item ex:extension _:ext . > _:ext rdf:value "xxx<other/>" . > _:ext ex:att "xxx" . > > > Is this worth writing up as a Pace for Atom? > > Ian > > >
Received on Friday, 14 January 2005 15:59:33 UTC