W3C home > Mailing lists > Public > www-rdf-interest@w3.org > March 2000

RE: API for RDF: locutor

From: Dan Brickley <Daniel.Brickley@bristol.ac.uk>
Date: Thu, 9 Mar 2000 10:48:12 +0000 (GMT)
To: Jan Grant <Jan.Grant@bristol.ac.uk>
cc: www-rdf-interest@w3.org
Message-ID: <Pine.GHP.4.21.0003091044340.20932-100000@mail.ilrt.bris.ac.uk>
On Thu, 9 Mar 2000, Jan Grant wrote:

> On Wed, 8 Mar 2000, Jan Grant wrote:
> 
> > 3. It's possible to envisage a higher-level API that builds on a
> > fundamental RDF API to support easy access to locutors- ie,
> > several levels of API that add value to underlying levels. Bear in mind
> > though that these are only an interface: the RDF model they present does
> > not have to be implemented (nor should it be) naively.
> >  However, it would be up to the implementation to 'fake' the existence
> > of RDF triples that are implicit in its locutor-friendly
> > implementation; since people can always drop back to the basic "ask
> > about the triples" style of querying the RDF model.
> 
> However, I would hasten to add that support for bag, sequence,
> alternative (and sets, sigh) membership should definitely be added to
> the API. The representation of these ideas in triples seems clunky at
> best and probably only useful for serialising RDF; I'd hate to think
> that people really were testing for A -_1-> B to determine bag
> membership :-(

There's also the rdfs:ContainerMembershipProperty as the class whose
members are _1 _2 etc, so you might in theory test for 
A -S1-> B and  S1 -rdf:type-> rdfs:ContainerMembershipProperty
given a query-oriented interface. Perhaps equally clunky, but doesn't
require anything new to be defined nor the backend to actually assign
_1, _2 etc properties for Bags. 
--dan
Received on Thursday, 9 March 2000 05:51:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:22 UTC