Not implemented: should use step to resolve to properties

Error message

Not implemented: should use step to resolve to properties

What it means

resolveNames in properties.go:36 switches on the concrete type of the PropertyPath. If it is a linkedql.PropertyStep (a step-based property path, e.g. nested path expressions), resolution to property IRIs is not implemented and this error is returned. It marks an unsupported, unfinished feature of the Properties step.

Source

Thrown at query/linkedql/steps/properties.go:36

// Properties corresponds to .properties().
type Properties struct {
	From  linkedql.PathStep      `json:"from"`
	Names *linkedql.PropertyPath `json:"names"`
}

// Description implements Step.
func (s *Properties) Description() string {
	return "adds tags for all properties of the current entity"
}

func resolveNames(names *linkedql.PropertyPath) (linkedql.PropertyIRIs, error) {
	if names == nil {
		return nil, fmt.Errorf("Not implemented: should tag all properties")
	}
	switch n := names.PropertyPathI.(type) {
	case linkedql.PropertyStep:
		return nil, fmt.Errorf("Not implemented: should use step to resolve to properties")
	case linkedql.PropertyIRIs:
		return n, nil
	case linkedql.PropertyIRIStrings:
		return n.PropertyIRIs(), nil
	case linkedql.PropertyIRI:
		return linkedql.PropertyIRIs{n}, nil
	case linkedql.PropertyIRIString:
		return linkedql.PropertyIRIs{linkedql.PropertyIRI(n)}, nil
	default:
		return nil, fmt.Errorf("Unexpected type")
	}
}

// BuildPath implements linkedql.PathStep.
func (s *Properties) BuildPath(qs graph.QuadStore, ns *voc.Namespaces) (*path.Path, error) {
	fromPath, err := s.From.BuildPath(qs, ns)
	if err != nil {
		return nil, err

View on GitHub (pinned to 81dcd7d73e)

Solutions

Replace the PropertyStep with explicit property IRIs or IRI strings in the Names field.
Flatten the path expression into concrete IRIs before constructing the step.
Contribute or wait for library support for step-based property resolution.

Example fix

// before
names := linkedql.NewPropertyPath(thePropertyStep)
// after
names := linkedql.NewPropertyPath(linkedql.PropertyIRIs{"http://xmlns.com/foaf/0.1/knows"})

Defensive patterns

Strategy: validation

Validate before calling

if _, isStep := names.PropertyPathI.(linkedql.PropertyStep); isStep {
  return fmt.Errorf("PropertyStep unsupported in Properties.Names; use explicit IRIs")
}

Type guard

func isSupportedPropertyPath(p linkedql.PropertyPath) bool {
  switch p.(type) {
  case linkedql.PropertyIRIs, linkedql.PropertyIRIStrings, linkedql.PropertyIRI, linkedql.PropertyIRIString:
    return true
  }
  return false
}

Try / catch

p, err := step.BuildPath(qs, ns)
if err != nil {
  if strings.Contains(err.Error(), "should use step to resolve") {
    return fmt.Errorf("replace PropertyStep with explicit property IRIs")
  }
  return err
}

Prevention

Use plain IRI lists in Properties.Names, not path steps
Flatten nested path expressions into concrete IRIs before building
Check library docs for supported PropertyPath implementations

When it happens

Trigger: Using a Properties step whose Names contain a PropertyStep (step-based path) instead of plain IRIs or IRI strings.

Common situations: Building queries with nested property path steps where simple IRI lists were expected; porting queries from other GraphQL-like APIs that allow path expressions.

Related errors

AI-assisted analysis of cayleygraph/cayley@81dcd7d73e (2026-09-06). Data as JSON: /api/errors/501cba06992e4412. Report an issue: GitHub.