RE: RDF terminology

Bill,

Thanks for your comments and suggestions.  Some comments below.

At 02:04 PM 1/5/01 +0000, Bill dehOra wrote:
>-Comments...
>
>Reification: I don't think you need to qualify "a reification of statement
>is not unique; there may be more than one reification of a statement" as
>your opinion. Whether or not such reifications can be conflated doesn't
>detract from these assertions being sound.

I agree that any such comments should be clearly not part of the 
definition.  For the time being, I'd like to place some markers for 
possibly controversial issues.

>Reified statement. I think this debate is concluded (well I can wish). Might
>as well hang myself: a statement can have an infinite number of
>reifications, until someone can explain to me how we can generally decide
>which binding resource in any of these reifications has primacy. Having an
>infinite number of reifications is a separate matter from the equivalence of
>these reifications.

Good.

>Representation: Can it be added that members of the RDF Formal Model, in
>implementations, are always representations of these entities?

Er, I'm not sure what point you're trying to make.  That implementations 
always deal in _representations_ of the formal model?

>Quoting: is this a generalisation of reification? That is, I don't
>understand the how Quoting a statement stands in relation to a statement
>reification.

I'd say that reification is one way that a statement can be quoted.  Other 
forms of quoting (e.g. TimBL's semantic toolbox) are not recogizable as 
reification (as we define it).  I think.

>Model: "(b) An RDF Model, meaning a collection of RDF statements". Maybe:
>"(b) An RDF Model, meaning a collection of RDF statement representations"

Hmmm... how formalistic do we want to be here?  I think we may have had 
discussions about RDF models that have not been dependent on any specific 
representation thereof.

>Context: "An environment within which some statements are taken to be true."
>Is this say that a context is a referent for the truth (or falsity) of a
>statement? Btw can we extend contexts to quantification? For a resource to
>have a context suggests to me that the resource is existentially quantified
>by that context...

I don't know about this.  My intuition that these are both matters of 
possible consequence rather that matters of definition (points for 
discussion in the Concepts section?).   Maybe it would be less confusing if 
this read:
   "An environment within which some statements are taken to be facts." ?
Although I can't offhand offer a definition of 'fact' other than "A true 
statement".  The change of wording is mainly an attempt to head of the idea 
the "truth" is subject to question (within the context).

>-Candidate additions...

Anything not mentioned here I've just copied into my working document.

>Entity: anything which exists or has existed. Web and RDF resources are
>entities (?). Unfortunately I don't have a definition for exists ;)

RFC2396 has a less general definition of (or assumption about) 
'entity':  as some data.  I'll put this in with a caveat about RFC2396 
usage.  Here's what I wrote:

   Entity:
     Anything which exists or has existed. Note that RFC2396 uses this term in
     a more restricted sense, to mean some data represents some aspect of a 
Web
     Resource.

Hmmm... I'm not so sure now if this is helpful.

>Resource: same as RDF Resource. More properly "RDF Resource" is used to
>distinguish "Resource" from "Web Resource".

I'd prefer to be more neutral about it being a web resource or RDF 
resource.  Sometimes (often) it may be both.  Here's my offering:

   Resource:
     May refer to an RDF resource or a Web Resource. Some resources may be 
both.
     In discussion of RDF, this term is often used to mean RDF Resource.


>Resource Identifier: "a URI plus optional anchor ID".[M&S] Resource
>Identifiers are understood to name Resources.

My offering:

   RDF Resource Identifier, Resource Identifier:
     A URI plus optional anchor ID.[M&S]
     RDF Resource Identifiers are understood to name RDF Resources.


>Referent: the entity that a Resource describes. [M&S]

I think this needs to be qualified as RDF Resource.

>Assertion Context: a context that asserts axiomatic truths. Or this where we
>stop regressing and say that things just are the case without requiring a
>further enclosing Context. Sorry, this is vague ... I wanted to address
>Pierre's point about context regression. This is just a Context that isn't
>nested inside another   Context.

Hmmm... I think this idea is up for debate.  Also:
(a) I think a context can assert axiomatic truths without being "top-level".
(b) I'm not sure that any context is truly "top level".  Any context is 
(possibly implicity) contained within another.  And might not a writer 
create an Escher-esque scenario in which the whole world or universe 
(including their writing) is a figment of the imagination of a character in 
their writing.  Whither "top-level" now ?-)
(c) I think that context nesting is not a static thing:  according to 
McCarthy/Guha, contexts are invoked dynamically by a chain of reasoning 
(they talk of "entering" and "leaving" contexts).  This is more like 
"activation records" than "lexical scope" in traditional block-structured 
programming languages.

However, I could accept a simpler definition along the lines of:

   Assertion Context:
     A context that asserts only axiomatic truths;  i.e. statements whose
     interpretation (and truth) is not dependent on any enclosing context.

>Star: the graph of a Reification, where the Reified Statement has the four
>arcs (type, subject predicate, object) in question.

I've never felt a need for this -- yet.  I'm inclined to put it on hold.

>Quad: the four statements that constitute a Reification. Probably redundant
>by now, we seem to be just using Reification.

We do sometimes talk about a "Reification Quad" -- I think it is useful
to include that:

   Reification Quad:
     The four statements that make up a Reification.

#g

Received on Friday, 5 January 2001 12:46:20 UTC