Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: situation-sensitive preferences #10

Open
saiedt opened this issue May 2, 2017 · 2 comments
Open

Feature request: situation-sensitive preferences #10

saiedt opened this issue May 2, 2017 · 2 comments

Comments

@saiedt
Copy link
Contributor

saiedt commented May 2, 2017

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:

A distinct characteristic or feature of a distinct resource. Using the RDF representation techniques, a context element in this sense can be identi ed 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:

subject predicate """select ..."""^^<https://www.w3.org/TR/rdf-sparql-query/>

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.

@cstockloew
Copy link
Member

I don't quite understand how the interface would be:

  1. 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).
  2. 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).

@Alfiva
Copy link
Member

Alfiva commented May 3, 2017

  1. Yes, I guess as the MW stands right now, it would be a mess trying to do that.
  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants