RE: Contexts (not again!)

heh - I just did another search for refs, and the top google for 'rdf
contexts' is a (Oct 2000) doc of Graham's.

 http://public.research.mimesweeper.com/RDF/RDFContexts.html

A quick skim would suggest that this approach is pretty close to what I had
in mind - is there a more recent version?

From Graham's doc this nicely sums it up :
A context is characterized by the fundamental relationship ‘is true in’, or
‘ist’, where:

[Statement] --ist--> [Context]

  I'm having trouble understanding your notion of "context".
  Paraphrasing your three properties:
      Resource has context = Statement
      Statement has contains = Resource
      Bag has contents = Resource

  errm, now I'm confused...

  This seems backwards to me.  I think of context
  as follows:
      Statement has context = cname
      cname is List of Statement

  yes, this is kind of what I had in mind, although I was also trying to
distinguish between the identifier of the context (cname/URI) and the
contained items {s1, s2, etc}


  Remarks:
  1. Although a Bag of Statements will work in some
  cases, I think that a List is necessary in general.

  I'm honestly not sure about this - the DAML/OWL folks seem to like the
List, but the way in which the items are accessed (head, tail) seems to me
to be rather orthogonal to the containship property, an unordered collection
that can contain duplicates (which I understand a bag to be) would seem to
be the important part.

  2. If you want to include actions (as opposed to static
  Properties), then context should include space and
  time.

  What's wrong with :

  cname {{{{

  s1 {
  danny isDoing typingStuff
  danny isIn office
  }

  s1 startTime 11am
  s1 endTime 11pm

  }}}}


  3. In my KR language, I put the context before the
  Statement (I call the static context "view")
      at view = cname { Statement }
  My static Statement is written as
      subject has predicate = object

  the RDF statement can be written

  <subject> <predicate> <object>

  which I'm hoping will work with

  <{<subject> <predicate> <object>}> <hasContext> <contextURI>


  Cheers,
  Danny.

  ============
  Dick McCullough
  knowledge := man do identify od existent done
  knowledge haspart list of proposition

    ----- Original Message -----
    From: Graham Klyne
    To: Danny Ayers
    Cc: RDF-Interest
    Sent: Wednesday, November 13, 2002 4:59 AM
    Subject: Re: Contexts (not again!)



    I think the "dark triples" approach fizzled out.  My take is that we're
not
    ready to standardize context mechanisms yet, but  still have hopes of
    prototyping my ideas in this area, which aren't vastly different from
what
    I think you're describing.  I think that reification, or a variation of
it,
    can be used (in a prototype implementation) to encode the triples that
    aren't asserted.

    In the longer run, a standard solution may call for something more
    "hard-wired", with scope for optimization.  I think this might come
about
    without invalidating/isolating the
    prototype approaches.

    #g
    --

    At 10:59 PM 11/2/02 +0100, Danny Ayers wrote:

    >Hi folks,
    >
    >Did any kind of consensus, or even decision (!?) result from Pat's
'dark
    >triples' suggestion [1] etc. earlier in the year (or any other of the
    >familiar context discussions)? I've had a look through the archives and
as
    >usual the threads are hard to follow. I'm wondering because I'm running
up
    >against this thing again.
    >
    >If there isn't anything sorted or on the cards in this area, I'd
appreciate
    >comments on the following first crack hackiness for a context
vocabulary.
    >I've not really got a grip on the reification angle with it yet, but
the use
    >I'm after is really just to be able to tag triples (make 'em quads in
    >memory), and it'd be nice to do it in a moderately sound fashion.
    >
    >Just three terms (the pseudo-schemas are undoubtedly way out) :
context,
    >contains, contents
    >
    >*context* - a group of statements (identified collectively by a single
URI)
    >with which a particular statement can be associated. In practice this
would
    >usually be
    >
    >[triple]-context->[RDF file]
    >
    >Property "context"
    >    domain Resource
    >    range Statement
    >    inverseOf contains
    >
    >
    >*contains* - the other way around,
    >
    >[RDF file]-contains->[triple]
    >
    >Property "contains"
    >    domain Statement
    >    range  Resource
    >
    >
    >*contents* - a list/collection whatever of (references to) the
statements to
    >be identified by a given URI (i.e. the triples in a file)
    >
    >Property "contents"
    >    domain Bag
    >    range Resource
    >
    >[RDF file]-contents->[s1, s2...]
    >
    >The first of these is probably all that I'd need, but the second
insisted on
    >coming along. The third heard there was a party.
    >When I started thinking of a way around this, the first thing that came
to
    >mind was a Context class, akin to a collection/bag, instances of which
could
    >be used to identify a file but with this it seemed to get messy a lot
    >quicker...
    >I'm pretty sure I'm badly conflating the unreified/reified triples
here, and
    >it does seem like it goes a bit beyond what can be expressed in RDF(S)
alone
    >(i.e. a minilayer on top) but I'm hoping that something usable won't be
far
    >away. I'm willing to bet there's something along these lines already,
but I
    >can think of worse ways to spend a Sunday evening.
    >
    >Cheers,
    >Danny.
    >
    >[1]
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Mar/0253.html
    >
    >
    >-----------
    >Danny Ayers
    >
    >Semantic Web Log :
    >http://www.citnames.com/blog

    -------------------
    Graham Klyne
    <GK@NineByNine.org>