W3C home > Mailing lists > Public > public-sw-meaning@w3.org > March 2004

Self-descriptive assertions

From: Mark Baker <distobj@acm.org>
Date: Mon, 22 Mar 2004 13:30:05 -0500
To: public-sw-meaning@w3.org
Message-ID: <20040322183005.GH19972@markbaker.ca>


I've got a simple requirement I need met, driven largely by my desire to
build RESTful Semantic Web apps.

When GETting some RDF from a URI, I need a self-descriptive path from
that representation to a statement about the "assertedness" of the
enclosed graph.  To not have that path is to introduce an ambiguity in
the semantics of the data as intended by the publisher of that data.

One very simple way to provide that path would be to say that all
RDF/XML documents described with the application/rdf+xml media type are
asserted.  Another would be to say that all are *un*asserted.  Yet
another would be to have some way of indicating in an RDF/XML document,
but outside the graph encoded within that document, whether some of the
triples are asserted or not.  There are certainly other approaches.

But currently, when considering the existing RDF specifications, and
the in-progress registration document for the application/rdf+xml
media type, there is no path, and therefore the aforementioned
ambiguity exists.

As I understand the discussion that happened on this list last year,
it seems that folks here have some extremely interesting ideas for
how this could best be managed going forward.  And that's great; I
don't want to take anything away from what might eventually make its
way down the pipe (though I hope it's still self-descriptive).  But I
*also* want to be able to be self-descriptive here and now, before all
that happens.  How can I do that?

FWIW, IMO, the simplest way forward is to say that publishing RDF/XML
using the application/rdf+xml media type asserts all the enclosed
triples, which is why I sent in this comment;


which spurned this thread;



Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Received on Monday, 22 March 2004 13:22:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:56:01 UTC