Re: RDF API 1.0 Draft / Triple vs. Statement?

R.van.Dort@Everest.nl wrote:
> 
> Sergey,
> 
> I really appreciate your work on the RDF API.

Thanks.

> I have played around a bit with GINF and I am very interested in a proper
> database implementation for 'RDF'.

I hope to get to it as soon as a basic agreement on the API is reached.
After that I'll release the database interface I'm playing with and the
new version of GINF adapted to the API.

> In relation to databases I write 'RDF' between quotes because RDF is a
> ...

(see reply from Danny Ayers)

> A very quick and unripe response to your RDF API 1.0 draft:
> why don't you use the RDF terminology: Statement instead of Triple? Model
> instead of RDFModel?

The reasons for that are "historical": SiRPAC used the notion of a
Triple. RDFModel was in GINF just Model. I changed it because Model is
such a general name that it can collide with other APIs.

But: personally I like your proposal and I'd change Triple into
Statement and RDFModel into Model, if nobody has objections.

RDF IG, are these names specific enough: Resource, Literal, Statement,
Model?? Pro/contra votes?

> I miss the explicit definition of Property: being an
> extension of Resource it certainly is a central entity in RDF.

Property is not in the API to avoid confusion. The point is that it
provokes the bad praxis to determine whether a resource is a property by
writing

	boolean isProperty = r instanceof Property;

This would not deliver false for:

	<rdf:Property rdf:ID="myProp"/> 

However, the information about resources that are definitely properties
is not lost, and you could still get it, since the predicate of every
statement must be a property.

The better way to deal with issues like the above is on the schema level
(the schema part of the API will be appended after we agreed on the
names of the interfaces for resources, literals etc.).

Thus, a SchemaModel (which will extend the VirtualModel), could be asked
for something like

	boolean isProperty = sm.find(r, RDF.type, RDF.Property).size() > 0;
or
	boolean isProperty = sm.contains(sm.createTriple(r, RDF.type,
RDF.Property));

and could derive the information correctly.

> I also want to make a plea for an interface Schema, as an extension of
> Model. A Schema as a container for resources of core RDF only.

The schema part of the API goes into org.w3c.rdf.schema, coming soon.

> Should we propose a package org.w3c.cg containing Node and Arc interfaces
> as a basis for RDF and an integration level for other (existing, like
> WebKB-GE, Notio, CharGer?) Conceptual Graph modeling tools?

That's an interesting idea. Frankly, it hard for me to see the practical
use of this generalization for the direction CG->RDF. For the opposite
one, we could get difficulties if we map a reacher model onto a simpler
one. For example, if Arcs in a particular app cannot be first-class
objects, i.e. nodes, the application could get confused.

Any other ideas?

Sergey

Received on Wednesday, 8 December 1999 17:23:55 UTC