Re: [DotGNU]Implement RDF in a Universal Data Structure

[Seth Johnson]

James Michael DuPont wrote:
> 
> --- Seth Johnson <address@hidden> wrote:
> 
> > The universal data structure represents all relations as Use Types
> > that are related to Link Types, each of which may be
> > particularized into specific Uses and Links.  A particular Use of
> > a certain Use Type represents the parent record of a relation, and
> > the particular Links of a certain Link Type represent the children
> > records related to that parent record:
> >
> >    Use Type: Shopping Cart
> >    Link Type: Products Selected
> >    Use: Seth's Cart
> >    Links: Soap, Shampoo, Milk, Butter, etc.
> >
> > (This is only a piece of the structure, but it represents the core
> > generalization that all the rest stems from)
> 
> OK, So Usage is the key abstraction. I dont understand how the shopping
> cart is the use type. Purchasing would be the use case, I think. The
> shopping cart is itself used. Otherwise, is the use type
> ShoppingCartUsage? So the usage of the shopping cart is the thing we
> are talking about. The Shampoo is what is in the cart. But what is the
> relationship between the cart and the shampoo? Contains?
> 
> Why not "ShoppingCart contains Shampoo"?


Okay, first, ShoppingCart>>Usage<< is implicit in the nature of the
abstraction.  I think you're talking about:

Use Type: ShoppingCartUsage
Link Type: Contains
Use: James' Cart
Links: Shampoo and stuff

You've made an RDF Predicate out of the Link Type, which I wasn't
illustrating here, tho I do illustrate RDF in my later example.  To finish
up the context to make it appropriate for RDF, you'd need the use type to
also be a general convention; i.e., Subjects in RDF nomenclature:

Use Type: Subject
Link Type: Contains
Use: James' Shopping Cart
Links: Shampoo, etc.

Once you've done that, you can query the server for all uses of the
"Subject" use type, that have links of the "Contains" link type.  That would
pull out all the triples relating subjects to objects by the "contains"
predicate.  You would get "James' Shopping Cart" plus all the items
contained in it, then "Seth's House" plus "door," "window," etc.

It seems to me that the "subject" use type serves merely to convey that the
intention of this particular context is specifically to be used for RDF.  It
doesn't seem to me that one has to limit queries to only such explicitly
RDF-intended use types and contexts, though.  More important for RDF is the
predicate, the link type which tells you exactly in what way the uses
(subjects) are related to the links (objects).

So you can actually just query the server for all uses that have links of
various "predicate" link types.  You could experiment with querying for any
old link type, too; but other contexts aren't necessarily intended to be RDF
knowledge assertions, and you would be using link types that weren't
intended as conventional RDF predicates.  It might still be fruitful; hard
to say.  Can any relationship between entities be treated as a set of RDF
assertions, even if the particular predicate type might not be specified or
might be non-standard?

When you say the use case should be purchasing, I hear you saying that the
more useful set of assertions in the case of a shopping cart scenario, is
assertions about purchases.  I think that's probably true, and your saying
so shows your penchant for modeling use cases in terms of knowledge
assertions of the RDF type.

In all of this, we're simply storing RDF triples in the universal data
structure for the purpose of querying it.  A CTP server context also
provides other functions which are less relevant to the purposes of basic
RDF.  Though one can use these other functions that are automatically
available to manage RDF triples.

The universal data store is about providing functionality; it goes beyond
supporting queries.  It goes beyond modeling assertions, to providing a 
universal data model designed to provide all the functions you need to
work with information.  A lot of the work going on in the RDF sphere, of
developing apps that make all sorts of different uses of RDF triples,
could be handled well just by declaring CTP contexts and using the
functions that the CTP server provides.  You'd just design whatever front
end you want, using the server to support the functions (like
manipulating pieces of information or outlining).

Seth Johnson

> 
> >
> > Once you have a universal data structure, you can define a
> > fundamental protocol that says everything you need to know
> > about any application, and you can store everything for
> > all applications in one universal structure that
> > inherently lets all elements in any particular such type
> > of relation, be used freely in any other such type of
> > relation.
> >
> > I refer to this fundamental relation as a "context."  It
> > can also be referred to as an atomic application.  A
> > context is an extended version of the traditional idea of
> > relations among data entities, turning that concept into
> > the core of the idea of what an atomic universal
> > application is necessarily made up of and must be able to
> > do.  More complex applications are simply made by
> > combining such atomic contexts.
> >
> > RDF can be stored in this data structure as follows:
> >
> >    Use Type: Subject
> >    Link Type: (Various predicates, like "has" "contains," etc.)
> >    Use: Whatever particular subject
> >    Links: Whatever particular "objects" asserted to relate in the
> > link type way to the particular subject.
> >
> >    Use Type: Subject
> >    LinkType: Has
> >    Use: Seth Johnson
> >    Links: arms, legs, a receding forehead
> >
> > What you can do with this is generalize about the universal
> > functions that must be built into such a representation of
> > a universal, atomic application.  This includes the query
> > functions that the RDF area focuses on.
> >
> > Build this into DotGNU.  Make a language that speaks in
> > terms of these abstractions.  I call the language CCL, or
> > Context Control Language, and I call the basic structure of
> > a context "packet" or "message" CTP, or Context Transfer
> > Protocol.  CTP can either be defined as something
> > immediately above TCP and immediately below the application
> > layer, in a binary way, or we could define it as something
> > correlative with HTTP, in a more textual way.
> >
> > There's more to it, but maybe this ramble will interest
> > some of you .
> 
> I am slowly getting to understand this..
> mike


-- 

DRM is Theft!  We are the Stakeholders!

New Yorkers for Fair Use
http://www.nyfairuse.org

[CC] Counter-copyright: http://cyber.law.harvard.edu/cc/cc.html

I reserve no rights restricting copying, modification or distribution of
this incidentally recorded communication.  Original authorship should be
attributed reasonably, but only so far as such an expectation might hold for
usual practice in ordinary social discourse to which one holds no claim of
exclusive rights.