You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A distinct characteristic or feature of a distinct resource. Using the RDF representation techniques, a context element in this sense can be identied uniquely by a pair of URIs, namely the URI of the resource and the URI of the corresponding property.
situation-sensitive preferences can be defined as context elements that have "dynamic values" (the value may differ from situation to situation). One way for specifying the value could be to use a SPARQL query as the value indicating that the actual value at each point in time should be determined by executing the query and using the query result as the actual value of such a situation-sensitive prerenece:
In that case, it would be nice if CHE could substitute the value of such a context element automatically whenever this context element is involved in a query passed to CHE, by first executing the "the value query" as a sub-query.
The text was updated successfully, but these errors were encountered:
I don't quite understand how the interface would be:
Send a context event with a query as value? In this case, you probably get problems, because ManagedIndividual will check that the value is correct (setProperty calls hasMember).
Send a query to CHE via service bus. How would the query look like? If you use a CONSTRUCT query, then it's already available; it's just a re-formulation of what you call a "sub-query" (the "sub-query" would basically be the WHERE clause).
Yes, I guess as the MW stands right now, it would be a mess trying to do that.
Sending arbitrary SPARQL queries to CHE through service bus is already possible.
I think I get what Saied wants to make, but it needs further ellaboration on how exactly that would turn out. What would be the outcome. Just for the record, I know some triple stores (IIRC including Sesame/rdf4j) have features to perform SPARQL queries on each "insert" and do something in return. This could be useful.
Referring to an old definition of a "context element" in http://forge.universaal.org/gf/download/docmanfileversion/12/504/20080917_AmI-08_PERSONA-Framework-Supporting-Context-Awareness.pdf:
situation-sensitive preferences can be defined as context elements that have "dynamic values" (the value may differ from situation to situation). One way for specifying the value could be to use a SPARQL query as the value indicating that the actual value at each point in time should be determined by executing the query and using the query result as the actual value of such a situation-sensitive prerenece:
In that case, it would be nice if CHE could substitute the value of such a context element automatically whenever this context element is involved in a query passed to CHE, by first executing the "the value query" as a sub-query.
The text was updated successfully, but these errors were encountered: