Issue with schema

[abourget]

Hi there, I've been searching for a bit of time now, a way to have this code work:

package broken

import (
	"testing"

	"github.com/cayleygraph/cayley"
	"github.com/cayleygraph/cayley/quad"
	"github.com/cayleygraph/cayley/schema"
	"github.com/stretchr/testify/assert"
)

func TestBroken(t *testing.T) {
	store, err := cayley.NewMemoryGraph()
	assert.NoError(t, err)
	store.AddQuad(quad.Quad{quad.IRI("dialect-source-file.raml#vocabularies/validation"), quad.IRI("http://www.w3.org/1999/02/22-rdf-syntax-ns#type"), quad.IRI("http://raml.org/vocabularies/meta#External"), nil})
	store.AddQuad(quad.Quad{quad.IRI("dialect-source-file.raml#vocabularies/validation"), quad.IRI("http://raml.org/vocabularies/meta#name"), quad.String("validation"), nil})
	store.AddQuad(quad.Quad{quad.IRI("dialect-source-file.raml#vocabularies/validation"), quad.IRI("http://raml.org/vocabularies/meta#uri"), quad.String("../vocabulary/validation.raml"), nil})

	schema.RegisterType(quad.IRI("http://raml.org/vocabularies/meta#External"), DialectExternal{})

	var dst DialectExternal
	assert.NoError(t, schema.LoadTo(nil, store, &dst, quad.IRI("dialect-source-file.raml#vocabularies/validation")))
	assert.Equal(t, "validation", dst.Name)
}

type DialectExternal struct {
	// rdfType struct{} `quad:"@type > http://raml.org/vocabularies/meta#External"`
	// ID      quad.IRI `quad:"@id"`
	Name    string   `quad:"http://raml.org/vocabularies/meta#name,optional"`
	URI     string   `quad:"http://raml.org/vocabularies/meta#uri,optional"`
}

This is using version baf955d

Running go test on that fails.

Anyone has insights ? I might have tripped over https://godoc.org/github.com/cayleygraph/cayley/schema#LoadTo where I read

Predicate IRIs in RDF can have a long namespaces, but they can be written in short form. They will be expanded automatically if namespace prefix is registered within QuadStore or globally via "voc" package. There is also a special predicate name "@type" which is mapped to "rdf:type" IRI.

Is it possible that this is not true ? That somehow Cayley expects the short form to be in the database ?

[abourget]

See discussions in https://discourse.cayley.io/t/difficulty-using-the-schema-package/1107/14 also.

[dennwc]

You are right about the short form - schema lib naively assumes that all IRIs match exactly on insert and in struct tags. However, the @type predicate is mapped to a short form, and resolution to full form is not done correctly, I guess.

It's time to do this properly. It will require all quad inserts to resolve to full form, and all queries to resolve their arguments to full form as well. For now, the best place for it is QuadStore.ValueOf and QuadStore.ApplyDeltas.

The downside is that users sometimes prefer to use short form, and now they will see a full form as an output of queries. Always printing short form will lead to the same confusion - written values might be in full form, while short form is returned as output.

[abourget]

What I was thinking is create a Schema strict and have a DefaultSchema like http.DefaultClient, and be able to configure the iriType in that reader. It would also allow the types to be registered within that Schema instance, as well as have its own reference to the QuadStore. Would simplify the arguments to LoadTo. The top level LoadTo could still use the DefaultSchema or create a new one on the fly, with the current defaults. What do you think? I wouldn't want to change the semantics for everyone or force the Data to be always full either. If it's this way, it's probably because some use the short form in their data. Le jeu. 22 févr. 2018 03 h 39, Denys Smirnov <notifications@github.com> a écrit :

…

You are right about the short form - schema lib naively assumes that all IRIs match exactly on insert and in struct tags. However, the @type predicate is mapped to a short form, and resolution to full form is not done correctly, I guess. It's time to do this properly. It will require all quad inserts to resolve to full form, and all queries to resolve their arguments to full form as well. For now, the best place for it is QuadStore.ValueOf and QuadStore.ApplyDeltas. The downside is that users sometimes prefer to use short form, and now they will see a full form as an output of queries. Always printing short form will lead to the same confusion - written values might be in full form, while short form is returned as output. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#694 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFs8MWBnJS233Htq4bQ8GPxni9JERu2ks5tXSeygaJpZM4SOSYP> .

[dennwc]

@abourget I think it's the best option for this particular case.

Note that graphql endpoint will still fail the same way (it also uses @type shorthand).

[dennwc]

@abourget Feel free to reopen if it does not cover your use case

[abourget]

Wow great! Thanks!

…

On Sat, Mar 3, 2018, 3:14 PM Denys Smirnov, ***@***.***> wrote: @abourget <https://github.com/abourget> Feel free to reopen if it does not cover your use case — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#694 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFs8Ko1AIzyELkx7R9TzJoIuXibXv0cks5tavmZgaJpZM4SOSYP> .