[Developers] State Quarters example and "need a unique result to attach here"

[John Giannandrea]

David Flanagan wrote:
> I understand that, but in this case (and as you point out), a US state
> is uniquely identified by its name and its type.  I'm wondering why,
> therefore, the expected type of the state property plus the name of  
> the
> state isn't sufficient to identify the state object I want.  (And  
> why is
> it confused about a city named Delaware?)

Hi David.

The type and name should be sufficient in this case.
Ids are great if you have the, but the requirement is just that you
define a unique thing in the clause (i.e. that if you did a MQL read  
with
that clause that you would get exactly one id back).

Your original question I think was why is the type not implicit?

The reason is that MQL doesn't enforce any types.
There is no requirement that the thing connected by the 'state'
property be a state.  i.e. in freebase the type system is not normative.
Its perfectly OK to put a person in that clause, should that make  
sense to you.

The rationale for doing this is the requirement of schema migration.
We have a "loose" typing system.  What started out as a set of  
us_state types
might end up as a set of us_regions_area types (example contrived)
and while the expected type of the property would change (ECT) there
is no requirement that all the data would be brought into line  
immediately
or in fact ever.  What is true is that the object would still remain  
the thing
we call Delaware, no matter what happened to the schema over time.

The expected type is just that, only an expectation of what kind of  
thing
is to be found in that clause.   This also explains why when you write  
something
in a subclause you have to specify the type also, you might think that  
MQL
could do it for you (and perhaps it should).

And as to your second question:
 > 3) Why isn't connect:insert or connect:update required here?

because you are doing a create at the top level, the connect is  
implicit.

I agree that the semantics of MQL write are subtle (to put it politely).
Im happy to work with you offline to explore the darker corners.

-jg