fluree / core

Fluree releases and public bug reports
0 stars 0 forks source link

Properties Introduced without `rdf:Property` Cause Issues in Queries #77

Open kellyprogramsthings opened 5 months ago

kellyprogramsthings commented 5 months ago

After creating a rdfs:Class and transacting an instance of that class, I can't select by listing properties and must use the wildcard for all the property values to come back.

Steps to reproduce: Create class test

{
  "ledger": "fluree-jld/369435906932736",
  "@context": {
    "f": "https://ns.flur.ee/ledger#",
    "owl": "http://www.w3.org/2002/07/owl#",
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "sh": "http://www.w3.org/ns/shacl#",
    "skos": "http://www.w3.org/2008/05/skos#",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "ex": "http://example.org/",
    "schema": "http://schema.org/"
  },
  "insert": {
    "@id": "ex:test",
    "@type": "rdfs:Class",
    "rdfs:label": "test",
    "rdfs:range": [
      {
        "@id": "first"
      },
      {
        "@id": "second"
      },
      {
        "@id": "third"
      },
      {
        "@id": "@type"
      },
      {
        "@id": "@id"
      }
    ]
  }
}

Add instance of that class

{
  "ledger": "fluree-jld/369435906932736",
  "@context": {
    "f": "https://ns.flur.ee/ledger#",
    "owl": "http://www.w3.org/2002/07/owl#",
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "sh": "http://www.w3.org/ns/shacl#",
    "skos": "http://www.w3.org/2008/05/skos#",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "ex": "http://example.org/",
    "schema": "http://schema.org/"
  },
  "insert": {
    "@id": "dude",
    "first": "two",
    "second": "three",
    "third": "one",
    "@type": "test"
  }
}

Query

{
  "where": {
    "@id": "?subject",
    "@type": "test"
  },
  "select": {
    "?subject": [
      "@id",
      "@type",
      "third",
      "first",
      "second"
    ]
  },
  "from": "fluree-jld/369435906932736",
  "@context": {
    "f": "https://ns.flur.ee/ledger#",
    "owl": "http://www.w3.org/2002/07/owl#",
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "sh": "http://www.w3.org/ns/shacl#",
    "skos": "http://www.w3.org/2008/05/skos#",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "ex": "http://example.org/",
    "schema": "http://schema.org/"
  }
}

Only returns

[
  {
    "@id": "dude",
    "@type": "test"
  }
]

Changing it to

  "select": {
    "?subject": [
      "*"
    ]
  },

causes everything to come back.

[
  {
    "@id": "dude",
    "@type": "test",
    "third": "one",
    "first": "two",
    "second": "three"
  }
]
aaj3f commented 5 months ago

(copying this from the discussion in Slack)

So I think I know why this is happening. I'm not sure it's a "bug", per se, but it's worth keeping in mind as we move forward, because if nothing else it is a stumbling block that I think many users will have.

One small note, in your first txn, you describe the class as ex:test and in the transaction you use "@type": "test", but I don't think that's the cause of the issue

Fluree treats (and currently needs to treat) data entities differently than it treats vocabulary-type entities (e.g. if I add a "property" entity, Fluree needs to treat that differently than if I add a "data model" entity like a "person" or an "achievement").

In your first transaction, you list those properties in the rdfs:range, but you're not indicating to Fluree that they're properties of any kind. So when Fluree first learns about those subject IRIs, it treats them as data entities, not properties.

If, for example, you'd "created" the ledger with the 2nd transaction (the one that adds data to dude), then Fluree would see those "first", "second", and "third" IRIs being used as properties in the insert statement and would implicitly add them as property entities.

You can see that the whole thing actually works as expected if this had been your initial transaction

{
  "ledger": "fluree-jld/369435906932736",
  "@context": {
    "f": "https://ns.flur.ee/ledger#",
    "owl": "http://www.w3.org/2002/07/owl#",
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "sh": "http://www.w3.org/ns/shacl#",
    "skos": "http://www.w3.org/2008/05/skos#",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "ex": "http://example.org/",
    "schema": "http://schema.org/"
  },
  "insert": {
    "@id": "test",
    "@type": "rdfs:Class",
    "rdfs:label": "test",
    "rdfs:range": [
      {
        "@id": "first",
        "@type": "rdf:Property"
      },
      {
        "@id": "second",
        "@type": "rdf:Property"
      },
      {
        "@id": "third",
        "@type": "rdf:Property"
      }
    ]
  }
}
aaj3f commented 5 months ago

When I say "worth keeping in mind as we move forward" I mean, maybe Fluree should handle this differently. For clarity, the reason we have to do that currently is for performance. We want the lookup table & caching process for schema/vocabulary related items to be smaller/faster than it would be if we had to do a whole lookup against ALL subject IRIs