Re: Self-descriptive assertions

> 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.

I don't know of a good answer to the problem as you have framed it,
but I'd be interested in knowing if an alternative framing actually
gives your users what they need.  The alternative framing comes from
thinking about who/what is doing the asserting; consider there to be a
different asserting entity for representations available from each
URI.  Now, whenever I give you a URI, you can get the graph, but you
have no idea whether to believe it.  You need trust metadata.  You
need me, as I hand you a URI, to say "this is true", and then you know
it's as true as what I say.  (Where the "I" there is actually another
URI/representation-dispenser.)

So in effect URI/Graphs assert (claim as true) other URI/Graphs.  You
start with some you believe; you get others.  You may have some you
know of without knowing whether to believe them, like when Google
gives you a hoax page.  So be it.   Good luck.

Does that make sense?  (I'm not saying it very well.)   Turn the
"asserted" problem over to the "trusted" problem, because if you can't
solve the "trusted" problem (well-enough for your app), you're out of
luck anyway.

      -- sandro

Received on Monday, 22 March 2004 13:50:55 UTC