Re: [TURTLE] Turtle Inverse Properties

On Wed, Aug 22, 2012 at 02:44:48PM +0100, Steve Harris wrote:
> On 2012-08-22, at 14:19, Yves Raimond wrote:
> 
> > On Tue, Aug 21, 2012 at 07:50:32PM +0100, Andy Seaborne wrote:
> >> 
> >> 
> >> On 21/08/12 13:38, Yves Raimond wrote:
> >>> As I see it, it is syntactic sugar that would make Turtle much easier
> >>> to use for some cases - in particular converting legacy data
> >>> structures.
> >> 
> >> Interesting - do you have an example of this you can show the list?
> > 
> > Sure (although I do think I posted it before), and this use-case was also mentioned in Tim's first email:
> > 
> > """
> > It is convenient for machine turtle writers.  If you can use the
> > is ...of syntax, then you can serialize any acyclic graph of bnodes without
> > having up make up nodeids for the serialzation, just using [brackets].
> > """
> > 
> > We do use https://github.com/moustaki/bbc-serialiser in various places on the BBC website to generate a set of machine-readable representations for our pages. The input for that is a JSON data structure, which is out of our control. For example that JSON might look like:
> > 
> > {
> >  "type":"episode",
> >  "id":"episode1",
> >  "brand":{
> >    "type":"series",
> >    "id""series1"
> >  }
> > }
> > 
> > When wanting to convert that to RDF, the ontology we use might only define a po:episode predicate, linking a series to an episode. As we reuse quite a lot of external ontologies, it is often the case that the predicates defined in those do not match exactly that first data structure. If we have a way to write inverse properties in Turtle, then in one pass of that data structure, given a simple declarative mapping, we can generate a valid Turtle string like:
> > 
> > :episode1 a po:Episode ; ^po:episode :series1 .
> > :series1 a po:Series .
> 
> or
> 
> :episode1 a po:Episode .
> :series1 a po:Series ; po:episode :episode1 .
> 
> Which gives the same graph.

For which you need to do what's described below - retain that 'po:episode' property and its object until you reach the object you can serialize it on. So you can't print that Turtle string as you iterate through the keys of that data structure.

> 
> > Otherwise, we have to generate a proper RDF model out of that data structure, and then generate the Turtle out of it. That's what we're doing right now (using EasyRDF), but it does make things significantly more complex.
> 
> I'm not sure I see where the difference is.
> 

In one case you iterate through the data structure and print a string that happens to be valid Turtle as you go along.

In the other case you need to construct an RDF-like model in memory to serialise the right thing.

One is slightly more expensive than the other :)

> > Hence, I do think syntactic sugar for inverse properties is useful to translate legacy data structures in RDF without having to use a full-fledged RDF library. It's really quite a similar use-case to @rev in RDFa, really. The way the data ends up being formatted might not match exactly the predicates defined in external ontologies (e.g. wanting to annotate a product-centric rather than offering-centric page with GoodRelations) so there's a need for some syntactic flexibility there.
> 
> @rev is a good example. There's cases in RDFa where it reduces the complexity (well, at least number of bytes) of saying things a lot, but it causes a lot of confusion in people new to RDFa. RDF is complex enough as it is IMHO.
> 

Yes, it's definitely a trade-off, but IMHO the balance tends towards adding a mechanism similar to @rev in Turtle.

Best,
Yves

> - Steve
> 
> -- 
> Steve Harris, CTO
> Garlik, a part of Experian
> +44 7854 417 874  http://www.garlik.com/
> Registered in England and Wales 653331 VAT # 887 1335 93
> Registered office: Landmark House, Experian Way, Nottingham, Notts, NG80 1ZZ
>

Received on Wednesday, 22 August 2012 14:03:24 UTC