[Data-modeling] CVTs: relations as first-class object

[Jeff Thompson]

Robert Cook wrote:
> Jeff --
> 
> One solution here is to "mediate" all relationships, making them CVTs,  
> which would give us this capability in the near term.  The problem  
> with this, as you can see from the developer mailing list, is that  
> CVTs confuse people trying to make a straightforward query, and many  
> of those people don't care that there is additional information  
> attached to the relationship.

The CVT is a true unappreciated star of Freebase.  A CVT is usually introduced
reluctantly to solve a problem, as if it is somehow a failure of the
original type design that, "Oh, well, I guess we now have to use a CVT."
On the contrary, CVT is a great technology that should be used enthusiastically,
because a CVT fills a need that Freebase originally didn't: it makes a
relation into a first-class object.  And MQL should recognize this and
treat the CVT as a first-class citizen, as a relation object which is
what every unmediated property really wants to be.

For example, in Topic Maps the relation is a first-class object.  Here is
how you say "John Smith works for the company ABC Corp.":
http://www.networkedplanet.com/technology/topicmaps/images/association-types.png
(From the page http://www.networkedplanet.com/technology/topicmaps/intro.html)

Now, see the attached image for how we already do the exact same thing in Freebase
using the "Employment Tenure" CVT.  Since it is a first-class object, we
easily attach the start and end dates for which the relation is true.
You can also attach provenance data, such as the who says that John Smith works
for ABC Corp.  And best of all, since the CVT has its own GUID, someone else
can refer to it and say "I think that is not true", etc.

This is great stuff.  Why treat CVTs as the unwanted visiting uncle?  Let's
celebrate them.  I have two suggestions for MQL:

1. The syntax of MQL already treats CVTs as a relations.  It should be
promoted as such.  Normally, to find Robert Cook's jobs where he was
director, you would center the query on the topic:
{
   "query" : [
     {
       "employment_history" : [
         {
           "company" : null,
           "title" : null,
           "title~=" : "Director"
         }
       ],
       "name" : "Robert Cook",
       "type" : "/people/person"
     }
   ]
}

But since "Employment Tenure" is a first-class relation, you can center the
query on the relation:
{
   "query" : [
     {
       "company" : null,
       "person" : "Robert Cook",
       "title" : null,
       "title~=" : "Director",
       "type" : "/business/employment_tenure"
     }
   ]
}

To me that's a lot easier.

2. If people only ever had one job, "Employment Tenure" would have been
a property, like a person's Weight.  This shows that the type of a
relation CVT is really the same as a property.
So....  I suggest that MQL should treat a property as a "virtual" relation CVT.
This allows forward compatibility as more properties are converted to relation CVTs.
For example, just like above, MQL should let me a write a relation-centered query for Weight:
{
   "query" : [
     {
       "person" : "Robert Cook",
       "floating_point_number" : null,
       "type" : "/people/person/weight_kg"
     }
   ]
}

where the default names "person" and "floating_point_number" are chosen based on their types.

Likewise, for the topic-centered query, if I ask for a property like this:
{
   "query" : [
     {
       "name" : "Robert Cook",
       "type" : "/people/person",
       "weight_kg" : null
     }
   ]
}
then MQL should think of the property as a "virtual" relation CVT as if I had written:
{
   "query" : [
     {
       "name" : "Robert Cook",
       "type" : "/people/person",
       "weight_kg" : {
         "floating_point_number" : null
       }
     }
   ]
}

and in fact allow me to use that.  Now, when we inevitably change the Weight
property in to a "Dated Float" CVT, if these two queries are treated as equivalent,
the transition can be painless.

- Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: John_Smith_works_for_ABC_Corp.JPG
Type: image/jpeg
Size: 27204 bytes
Desc: not available
Url : http://lists.freebase.com/pipermail/data-modeling/attachments/20080223/ca0ac3f9/attachment-0001.jpeg