Open kellyprogramsthings opened 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"
}
]
}
}
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
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
Add instance of that class
Query
Only returns
Changing it to
causes everything to come back.