RDF API... Alive?

Hello!

I've been happy to find RDF API at
http://www-db.stanford.edu/~melnik/rdf/api.html
that's really what I need for my work on representation of information
about programming contests (participants, problems, results, etc -
we're doing it as a part of the automated judging system development
for NEERC http://neerc.ifmo.ru and ACM ICPC http://acm.baylor.edu).
I've been looking just for this kind of API, because I'm not satisfied
with W3 RDF syntax (too verbose) and want to play with others (like
Strawman). I'm qurious - is the project still alive (seems like it has
not been updated for more than a year)? Any plans to move to the
latest Java 2 APIs (Collection framework's iterators instead of
Enumerations and JAXP instead of build-in and proprietary-configured
XML parser)?

And one more question: I need higher-order constructs (at least
aboutEach, that was removed from the latest RDF revision) and I'd plan
to have kind of "attribute overriding" policy (to set specific
attributes for some resource and override those made with
"aboutEach"). I've been planing to have a simple rule: the last (in
document order) attribute value takes precedense. That is why I need
an API that guarantees a stable order of emited Statements (that
correspond to the document order). Does org.w3c.rdf.model.Model and
parsers gurantee that the document order of Statements is preserved?

Btw, here's the copy of my e-mail to www-rdf-comments@w3.org on the
similar issue:

This is a forwarded message
From: Roman Elizarov <elizarov@acm.org>
To: www-rdf-comments@w3.org
Date: Monday, January 28, 2002, 9:38:28 PM
Subject: aboutEach

===8<==============Original message text===============
Hello!

I've been watching very closely the W3 RDFCore working group. I'm
developing XML-based knowledge representations for my field field of
study (programming contests, etc) for a while and found RDF to be a
good (and standard) way to represent relations that I need.

I've been almost ready with the moving of all my data to RDF, but was
set back by the lastest RDFCore resolutions. The problems is: I not
only want to have a quite flexible representation of my data-graphs
(entities and relation), but to be able to type and edit (sic!) them
(mostly) by hand.

So if I have, say 100 resources and I want to attach a common property
to them (which happens often), then "aboutEach" is the great tool for
me (actually, "aboutEachPreffix" was even better - you need not waste
space and time creating bag for them).

More over, it is often the case when I need to have specific
properties for a couple resources of that 100. Though, RDF spec does
not say anything about overriding properties (accourding to spec you
may have the same property multiple times) I was hoping use a simple
domain-specic rule - always use the last (in document order) property
value set. Unfortunately, RDF spec does not mandate any particular
order in which N-Triples are generated from the document, does it?
(Why not, by the way?)

I undendarstand the reason why "higher level" tools like aboutEach and
aboutEachPrefix are removed from RDF_Core_, but is there any other
work going on some "higher level" standard for RDF, so that higher
level amounts of N-Triples can be generated from the input document?
RDFCore intent seems to generate a number of N-Triples directly
(lineraly) proportional to the input document size only and this is Ok
for RDF_Core_, but it has too limited application. Actually, even more
higher level tools are required for many applications, for example,
the ability to "borrow" attributes from the other resource by
specifing it as a target of some special property (that's what I
need... but that I can do in a domain-specific way, though it's not
that elegant... but I suppose there's a lot more).

Is anybody working on the "higher level RDF"? Maybe you can recommend
other XML-based generic (flexible) knowledge representation languages
that contain higher level primities?

// Please CC replies to elizarov@acm.org

-- 
Best regards,
 Roman                          mailto:elizarov@acm.org

Received on Tuesday, 29 January 2002 00:18:23 UTC