Is there a way to get a specific index of the pointer?

[danielbeeke]

I have the following code:

  render () {
    const namesPointer = this.dataPointer().out([this.predicate])

    // My question is about the following three lines.
    const indexSpecificNamesPointer = namesPointer.clone({
      ptrs: [namesPointer.ptrs[this.index]].filter(Boolean)
    }).trim().out([schema('name'), rdfs('label')])

    const name = bestLanguage(indexSpecificNamesPointer, this.uiLanguagePriorities)


    this.innerHTML = `<h2>${name ?? this.value?.value} <em>(blank node)</em></h2>`
  }

A possible syntax might be:

  render () {
    const namesPointer = this.dataPointer()
      .out([this.predicate])
      .index(this.index)
      .out([schema('name'), rdfs('label')])

    const name = bestLanguage(indexSpecificNamesPointer, this.uiLanguagePriorities)


    this.innerHTML = `<h2>${name ?? this.value?.value} <em>(blank node)</em></h2>`
  }

What do you think? Is something like this already in the library or would you be open to a PR for this?

[bergos]

If the method is added, it should be .at() like it's defined for Array.at. But I have to reflect a little bit more how it works with different use cases.

The ptrs are in order of the given predicates, but if there are multiple triples with the same predicate, the order depends on how Dataset.match() returns them, and that order is not defined. A missing triple also ruins the index.

It would be possible to access a specific index with [...ptr][index]. Doing it like that shows more explicitly that one relies on the iterator with all consequences. A .at() method may suggest there are more guarantees than there are actually.

[danielbeeke]

Yes my use case is about one predicate with multiple values.
Yes I see, I do not care to much about the specific order, but it would be great if it is consistent.

at() sounds great and I see a bit more now about the complexity. Thanks!

[danielbeeke]

What do you mean with "A missing triple also ruins the index."?

[bergos]

If you have the following triples:

<>
  propertyA "a";
  propertyC "c".

Now you traverse them with Grapoi like this:

const result = ptr.out([ns.ex.predicateA, ns.ex.predicateB, ns.ex.predicateC])

You may expect that result.values look like this: ['a', 'b', 'c'], but actually, it's ['a', 'c'].

-> You don't have the guarantee that the predicate index matches the result index.

[danielbeeke]

Ah, I see.
What if .at(predicate, index) would always just get objects for one predicate?

[danielbeeke]

An alternative could be:

const firstPointer = pointer.out(predicate).at(1)
// firstPointer is a grapoi pointer with only the first ptr.

const firstPointer = pointer.out([predicate]).at(1)
// Throws exception, .at() can only be used on one predicate.

[danielbeeke]

@bergos what do you think of this last idea?