Re: [TURTLE] Turtle Inverse Properties

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 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 .


:episode1 a po:Episode .
:series1 a po:Series ; po:episode :episode1 .

Which gives the same graph.

> 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.

> 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.

- Steve

Steve Harris, CTO
Garlik, a part of Experian
+44 7854 417 874
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 13:45:23 UTC