Leo Simons has
posted
about the design choices they've made - notably :
No bnodes
He gives an example, along with the advantage it brings to the
code (less nested loops). It's a bit hard to extrapolate from
though - the example involves a list, which is a fairly particular
situation.
The idea of only using a subset of RDF/RDFS has been discussed a
good few times before (orthogonally to the XML syntax permathread).
Ian Davis brought it up in
Crisis,
which Shelley then
tossed
in oil. Basically reification seems more trouble than it's
worth (especially when named graphs are available), containers are
misleading, collections can be hard work. Containers/collections
were a specific aspect of RDF the Metaweb folks mentioned as
lacking. I think someone else has been playing with RDF without
resources -
or did I dream that...
All that stuff doesn't sound unreasonable to me, a lot of it
could be seen as a side effect of preferring simpler, more
performant designs. Having said that, I'm not entirely convinced by
Leo's comparison in terms of making life easier for the coder - in
other cases sugar may be an option, or a completely different
approach, like
Just Use SPARQL.
I would worry a bit about the side effects a policy of
no bnodes in general might produce - either the domain
models have to be bent to fit and/or logic being moved from the
data model into the code, undermining the benefits of a declarative
approach. (Whatever, I don't think any of it calls for any spec
changes, the tools are generally mature enough that it is possible
to pick & choose features).
[I wonder if there's an RDF
and OWL 1.1 compatible profile (not Full) containing most
of RDF/S, including existentials - but no reification or containers
- plus FPs & IFPs, and that's about all. It would be good to
have an 80/20 that could work alongside simple data models as well
as the fanciest reasoners. Must read up.]
I also wonder if the recent
revised
abstract model for Dublin Core might help any with the
example Ian used in his crisis post.
PS. Oops, nearly forgot the link there. Anyhow, forget the
implementation details for now, go read this post from Bob DuCharme
on
Semantic
data entry.
@en