RE: Contexts (spinoff from copy and wrap rdf statements)

Re: Contexts (spinoff from copy and wrap rdf statement

  I still prefer to think of the resource being the information, and any
particular document being a representation of the resource. For example, say
<http://example.org/privacy> is the URI of a company's privacy policy, which
might be available in multiple languages and formats and might vary over
time. The actual bytes which you would receive (the representation) will
vary, but the resource is constant.

  Put like that I would probably agree with with you. But I was really
trying to get an idea of how best to deal with a particular kind of
representation, the RDF document.


  Similarly, I would think of <http://somewhere/me.rdf> as being a dataset
which can be expressed in terms of triples.
  Any RDF documents you get as a result of dereferencing the resource would
be representations.

  But how are those representations to be interpreted?
  If the RDF document at http://example.org/c.rdf contained the triple:

  Sassi hasSpecies Cat

  and (elsewhere) I asserted

  http://example.org/c.rdf  is true

  would I be saying simply

  Sassi hasSpecies Cat

  or

  http://example.org/c.rdf says "Sassi hasSpecies Cat"
  ?

  This is rather an artificial example, consider a more realistic example:

  http://example.org/c.rdf  dc:Creator Sambuca

  What does that mean in terms including the triples found in c.rdf?
  Is it equivalent to the statements:

  {
  http://example.org/c.rdf  dc:Creator Sambuca
  Sassi hasSpecies Cat
  }

  or

  {
  http://example.org/c.rdf  contains S1
  S1 subject Sassi
  S1 predicate hasSpecies
  S1 object Cat
  }




  If you needed to refer to an actual RDF/XML document that you downloaded
at a specific time, you could use something like:


  _:a rdf:type eg:Representation;
      dc:source <http://somewhere/me.rdf>;
      dc:format "application/rdf+xml";
      dc:language "en";
      dcq:issued "2002-11-23t10:30:00z".

  This is certainly useful, but it doesn't deal with the issue above.

  Cheers,
  Danny.