IRI doesn't in db, but want to create a temporary one for predict any possible ?
The following functions are available:
-
IRI
- creates a new IRI and requires a string argument -
BNODE
- can be used with or without a string argument to generate a new bnode -
UUID
- generate a IRI using a UUID as the label
UUID() or BNODE() would usually be the easiest if you don't need to correlate across solutions, eg BIND(UUID() as ?newResource)
.
INSERT DATA {
:v1status1 rdfs:subClassOf
[ rdf:type owl:Restriction ;
owl:onProperty :v1 ;
owl:someValuesFrom
[ rdf:type rdfs:Datatype ;
owl:onDatatype xsd:integer ;
owl:withRestrictions ( [ xsd:minExclusive "60"^^xsd:integer ]
[ xsd:maxInclusive "90"^^xsd:integer ]
)
]
] .
:v2status1 rdfs:subClassOf
[ rdf:type owl:Restriction ;
owl:onProperty :v2 ;
owl:someValuesFrom
[ rdf:type rdfs:Datatype ;
owl:onDatatype xsd:integer ;
owl:withRestrictions ( [ xsd:minExclusive "90"^^xsd:integer ]
[ xsd:maxInclusive "140"^^xsd:integer ]
)
]
] .
:v1status2 rdfs:subClassOf
[ rdf:type owl:Restriction ;
owl:onProperty :v1 ;
owl:someValuesFrom
[ rdf:type rdfs:Datatype ;
owl:onDatatype xsd:integer ;
owl:withRestrictions ( [ xsd:minExclusive "0"^^xsd:integer ]
[ xsd:maxInclusive "59"^^xsd:integer ]
)
]
] .
}
i have something like this predefined.
but i want to predict some temporary variable belong to status if its value in range
What does your query look like? I don't understand what you mean "predict some temporary variable". Is it a value which should be used to group multiple results in the query?
Or are you going to use this in a rule?
such individual doesn't exist in database, but make a temporary to predict it belongs a owl:Class
like this one
:Teenager rdfs:subClassOf
[ rdf:type owl:Restriction ;
owl:onProperty :hasAge ;
owl:someValuesFrom
[ rdf:type rdfs:Datatype ;
owl:onDatatype xsd:integer ;
owl:withRestrictions ( [ xsd:minExclusive "12"^^xsd:integer ]
[ xsd:maxInclusive "19"^^xsd:integer ]
)
]
] .
i want to get :Teenager if a temporary individual :hasAge is 17
Ok, I don't think you need anything temporary here. Your "subClassOf" form is backwards. Try reversing it (put Teenager on the object position of the triple).
INSERT DATA {
:Teenager rdfs:subClassOf
[ rdf:type owl:Restriction ;
owl:onProperty :hasAge ;
owl:someValuesFrom
[ rdf:type rdfs:Datatype ;
owl:onDatatype xsd:integer ;
owl:withRestrictions ( [ xsd:minExclusive "12"^^xsd:integer ]
[ xsd:maxInclusive "19"^^xsd:integer ]
)
]
] .
:c :hasAge "17"^^xsd:integer
}
and why this doesn't give me
:c rdf:type :Teenager
SELECT *
WHERE {
:c ?p ?o .
}
you need to change it to:
crapthings
40m
INSERT DATA {
[ rdf:type owl:Restriction ;
owl:onProperty :hasAge ;
owl:someValuesFrom
[ rdf:type rdfs:Datatype ;
owl:onDatatype xsd:integer ;
owl:withRestrictions ( [ xsd:minExclusive "12"^^xsd:integer ]
[ xsd:maxInclusive "19"^^xsd:integer ]
)
]
]
rdfs:subClassOf :Teenager.
:c :hasAge "17"^^xsd:integer
}
Perhaps take a look at the OWL 2 primer if this is not clear: OWL 2 Web Ontology Language Primer (Second Edition)
If it's not working, please share the query plan for
SELECT *
WHERE {
?x a :Teenager
}
wow this really solve the problem if resource in database.
but what if :c is not in database and such query is to complicate for real scene
there will too many DataProperties in or not in OPTIONAL, and to predict an resource is relate to another resource
SELECT
?what1
# ?what2
WHERE {
{
?find1 ?whatever1 :hasAge .
?find1 (<>|!<>)*/xsd:minExclusive ?lmin .
?find1 (<>|!<>)*/xsd:maxInclusive ?lmax .
FILTER (?val > ?lmin && ?val < ?lmax) .
?what1 (!<>)* ?find1 .
BIND(17 as ?val)
}
so should i insert tripple temporary and then remove later or there's a way to use a temporary vaiable?
Is ?find1
something in your database? I don't understand what this query is doing. If you want to create a new resource, you can use the functions as I mentioned earlier. If you are using it in a rule, best to create a bnode/iri with a string argument so it can be consistent across rule invocations.
sorry about my english, im trying hard to explain.
knowledge persist in stardog db, but some data are in mongodb and other data source.
i just want to query it runtime or in a session.
so bind temporary IRI or bnode and give it statement that doesn't USE INSERT clause .
can solve the problem but that ?person saved to db, any possible to not use INSERT.
just statement it in WHERE
INSERT {
?person :hasAge 17 .
}
WHERE {
BIND(IRI(UUID()) as ?person).
}
SELECT ?person
WHERE {
?person a ?class .
}
I understand your English, but I don't understand what you're trying to do. Since you mentioned MongoDB, it sounds like you're asking if reasoning will work with virtual graphs. In general the answer is yes, but there are a few limitations compared with data stored natively in the RDF index. The IRI generated by the virtual graph query will function just the same as IRI stored in the RDF index. You don't need to insert any data to query a virtual graph with reasoning.
not just mongodb, my stack is javascript. data might in json form comes anywhere.
and in this case i don't use virtual graphs( but virtual graphs is awesome).
i want to construct axiom in memory and use that to get reasoning result in a query session
I think you should insert it into the database in that case. You don't need to commit the transaction to query the data.
or virtual graph is not just for mongodb, its a term virtual(in-memory graph)
The query is answered over the "logical" database (RDF data + virtual graphs). There's no way to inject data for reasoning+query externally except for virtual graphs. To make your data available to query, it sounds like the easiest solution would be to add it to the database.
it sounds okay, but what if same resource are asked by other user.
DELETE
INSERT
WHERE
this can be solve use random iri to avoid conflict.
but database will still grow.
i have to remove all temporary tripples frequently
and looks save to db that makes query twice?
Using the default snapshot isolation will give you the ability to work with potentially overlapping data in separate transactions without them interfering with each other. You can add data, perform your queries, and rollback the transaction. The data will not appear permanently in the database. However, the files on disk will be modified and this may need to be vacuumed/optimized over time although this happens automatically via compactions at some point.