Re: Trying to count the properties used for each class
Hey Bob,
does this one do what you're after?
SELECT DISTINCT ?cl (COUNT(DISTINCT ?p) AS ?c)
WHERE {
?s a ?cl .
?s ?p ?o .
}
GROUP BY ?cl
Nicola
Il giorno lun 24 gen 2022 alle ore 23:05 Bob DuCharme ha
scritto:
> Using arq and the data at
> http://www.snee.com/bobdc.blog/files/BeatlesMusicians.ttl, I’m trying to
> write a query that will list the classes used in the data and the number
> of distinct properties used by instances of that class. I’m having a
> hard time and can’t even write a query that lists the number of
> properties used for just one of the classes; the following just shows me
> a series of ones.
>
> SELECT (COUNT(DISTINCT ?p) AS ?pcount)
> WHERE {
>?s a .
>?s ?p ?o .
> }
> GROUP BY ?p
>
> Any suggestions?
>
> Thanks,
>
> Bob
>
>
Re: Trying to count the properties used for each class
You're counting the same thing you're grouping by. I think you need:
SELECT ?c (COUNT(DISTINCT ?p) AS ?pcount)
WHERE {
?s a ?c .
?s ?p ?o .
}
GROUP BY ?c
http://sparql.org/sparql?query=SELECT+%3Fc+%28COUNT%28DISTINCT+%3Fp%29+AS+%3Fpcount%29%0D%0AWHERE+%7B%0D%0A+++%3Fs+a+%3Fc+.%0D%0A+++%3Fs+%3Fp+%3Fo+.%0D%0A%7D%0D%0AGROUP+BY+%3Fc=http%3A%2F%2Fwww.snee.com%2Fbobdc.blog%2Ffiles%2FBeatlesMusicians.ttl=text=%2Fxml-to-html.xsl
On Tue, Jan 25, 2022 at 12:05 AM Bob DuCharme wrote:
>
> Using arq and the data at
> http://www.snee.com/bobdc.blog/files/BeatlesMusicians.ttl, I’m trying to
> write a query that will list the classes used in the data and the number
> of distinct properties used by instances of that class. I’m having a
> hard time and can’t even write a query that lists the number of
> properties used for just one of the classes; the following just shows me
> a series of ones.
>
> SELECT (COUNT(DISTINCT ?p) AS ?pcount)
> WHERE {
>?s a .
>?s ?p ?o .
> }
> GROUP BY ?p
>
> Any suggestions?
>
> Thanks,
>
> Bob
>
Trying to count the properties used for each class
Using arq and the data at
http://www.snee.com/bobdc.blog/files/BeatlesMusicians.ttl, I’m trying to
write a query that will list the classes used in the data and the number
of distinct properties used by instances of that class. I’m having a
hard time and can’t even write a query that lists the number of
properties used for just one of the classes; the following just shows me
a series of ones.
SELECT (COUNT(DISTINCT ?p) AS ?pcount)
WHERE {
?s a .
?s ?p ?o .
}
GROUP BY ?p
Any suggestions?
Thanks,
Bob
Mapping multiple files into the same namespace
Hi, I want to merge multiple RDF files into a single ontology under one namespace URI. E.g. to add custom assertions to ontologies without touching their original files. Can LocationMapper/FileManager be made/extended to do this, or do I need to roll something of my own? Martynas atomgraph.com
Re: Dynamically restricting graph access at SPARQL query time
You're more than welcome :) On Mon, Jan 24, 2022 at 3:41 PM Vilnis Termanis wrote: > > Hi Martynas, > > Thank you very much for the suggestion (and additional information > out-of-band). > I've been having a look at LinkedDataHub and will come back to you > with some questions, if you don't mind. > > Regards, > Vilnis > > On Fri, 21 Jan 2022 at 15:26, Martynas Jusevičius > wrote: > > > > WebAccessControl ontology might be relevant here: > > https://www.w3.org/wiki/WebAccessControl > > We're using a request filter that controls access against > > authorizations using SPARQL. > > > > On Fri, Jan 21, 2022 at 4:13 PM Vilnis Termanis > > wrote: > > > > > > Hi, > > > > > > For a SPARQL query via Fuseki, we are trying to restrict visibility of > > > groups of triples (each with multiple subjects) dynamically, in order > > > to allow for generic queries to be executed by users (instead of > > > providing tinned ones). > > > > > > Looking at the available ACL mechanisms in Jena/Fuseki, I assume > > > storing each of these groups as a distinct graph might be the way > > > forward. (The expectation is to be able to support 10^5 or higher > > > number of these.) > > > > > > I.e.: Given a user (external to Fuseki, e.g. presented via shiro via > > > LDAP/other), only consider triples from the set of graphs 1..N during > > > the query. (Where the allowed list of 1..N graphs is to be looked up > > > at the point of the query.) > > > > > > From my limited understanding, some potential routes are: > > > > > > a) jena-fuseki-access - Filters triples at storage level via "TDB Quad > > > Filter" support in TDB. > > > However, the configuration of allowed graphs per user is static at > > > runtime. > > > > > > b) jena-permissions - Extends the SPARQL query engine with an Op > > > rewriter which allows a user-defined evalulator implementation to > > > allow/deny access to a graph/triple, given a specific user/principle. > > > (The specific yes/no evaluation responses are cached for the duration > > > of a query/operation.) > > > However, this can only applied to a single graph as it stands. > > > > > > c) Parse & re-write the query to e.g. scope it using a fixed set of > > > "FROM" clauses. From some minimal testing (with ~200 FROM clauses) > > > this does not appear to perform well (compare to a tinned query which > > > explicitly restricts access via knowledge of the ontologies involved). > > > I appreciate that maybe having a large list of FROM clauses is an > > > anti-pattern. > > > > > > My questions are: > > > > > > 1) Does filtering to a set of subset of graphs (from a large set of > > > graphs) to restrict access sounds like a sensible thing to do? (Note > > > that each of these graphs would contain a set of multiple subjects - > > > i.e. we are not trying filter by specific predicate/object values.) > > > > > > 2) Would extending either jena-fuseki-access to support the > > > user-graph-list lookup dynamically OR extend jena-permissions to work > > > at dataset level be sensible things to do? > > > > > > 3) If the answer to either of (2) is yes - I'd be interested in > > > getting a better understanding of what would be involved to gauge the > > > size/effort of such an extension. I have had a look codebases for the > > > aforementioned projects, but my knowledge of TDB/ARQ/etc is very > > > limited. (We'd potentially be interested in taking this on, time & > > > priorities permitting.) > > > > > > I didn't know which mailing list to send this to but I thought the > > > users list would probably be a better starting point. > > > > > > Regards, > > > Vilnis > > > > > > -- > > > Vilnis Termanis > > > Senior Software Developer > > > > > > e | vilnis.terma...@iotics.com > > > www.iotics.com > > > > -- > Vilnis Termanis > Senior Software Developer > > m | +44 (0) 7521 012309 > e | vilnis.terma...@iotics.com > www.iotics.com > > The information contained in this email is strictly confidential and > intended only for the parties noted. If this email was not intended > for your use, please contact Iotics. For more on our Privacy Policy > please visit https://www.iotics.com/legal/
Re: Dynamically restricting graph access at SPARQL query time
Hi Andy, Hope you're well - nice to hear from you. (responses inline) On Sat, 22 Jan 2022 at 13:57, Andy Seaborne wrote: > > > > On 21/01/2022 15:26, Martynas Jusevičius wrote: > > WebAccessControl ontology might be relevant here: > > https://www.w3.org/wiki/WebAccessControl > > We're using a request filter that controls access against > > authorizations using SPARQL. > > > > > On Fri, Jan 21, 2022 at 4:13 PM Vilnis Termanis > > wrote: > >> > >> Hi, > > Hi Vilnis, > > >> For a SPARQL query via Fuseki, we are trying to restrict visibility of > >> groups of triples (each with multiple subjects) dynamically, in order > >> to allow for generic queries to be executed by users (instead of > >> providing tinned ones). > > >> Looking at the available ACL mechanisms in Jena/Fuseki, I assume > >> storing each of these groups as a distinct graph might be the way > >> forward. (The expectation is to be able to support 10^5 or higher > >> number of these.) > > If each graph is in the same TDB dataset, graph numbers are not much > different from any other node frequency. Millions of graphs are > possible. It's all quads. 4 Node/NodeIds. Great, that's what I was hoping. > > So it might be a way forward (details matter...) > > Managing said dataset is another matter. > > The description sounds a bit SOLID-like - see Martynas's comment > and -> https://inrupt.com. > > >> I.e.: Given a user (external to Fuseki, e.g. presented via shiro via > >> LDAP/other), only consider triples from the set of graphs 1..N during > >> the query. (Where the allowed list of 1..N graphs is to be looked up > >> at the point of the query.) > > How often is LDAP being accessed per query execution? Going off machine > is a significant cost compared to triple access. (From experience of > others, LDAP servers can be "unhelpful" - e.g. big spread in the latency > of requests based on environmental factors). I think I could have worded that better: Given a provided (at query time) user/Principal (which Fuseki/Jena does not have to authenticate), only consider graphs 1..N (determined based on the principle.) > (shiro is only integrated for Fuseki/webapp - it does work with > Fuseki/main but you have to add it. Current WIP should, eventually, > improve this.) > > >> From my limited understanding, some potential routes are: > >> > >> a) jena-fuseki-access - Filters triples at storage level via "TDB Quad > >> Filter" support in TDB. > > Yes. Filtering is a hook to use. Sounds like your UC might need its own > filter code (in Java) for the policy. > > >> However, the configuration of allowed graphs per user is static at runtime. > > jena-fuseki-access is a layer on top of the filtering mechanism for the > common case of ACLs on named graphs. That layer isn't compulsory for > quad filtering. The code may be inspiration for setup of custom code. >From your perspective, if the UC is indeed only about graph-level filtering (and not more granular), are there specific pros/cons of implementing such a filter using the TDB quad hook VS query engine op rewriting? Is the former more efficient (due to being lower-level maybe?) or do they both in the end have a very similar job - exclude matched quads if their graphs are no in the allowed list. > > >> b) jena-permissions - Extends the SPARQL query engine with an Op > >> rewriter which allows a user-defined evalulator implementation to > >> allow/deny access to a graph/triple, given a specific user/principle. > >> (The specific yes/no evaluation responses are cached for the duration > >> of a query/operation.) > > From what I know, should work. Claude may be able to say more. > > >> However, this can only applied to a single graph as it stands. > > A dataset is a collection of named graphs. Each graph can have > jena-permissions wrapped around it. Indeed - what I wasn't sure about is how that wrapping would work in the "any-number-of-graphs" (as opposed to fixed via config) case so assumed there might be some extra work to move it up a level, to dataset. (I found a thread from 2018 where it's suggested this: https://markmail.org/message/z5tsgblnqivpdqvy ) > > Your UC description was about groups of triples, and then it slid into > named graph. Is NG points above and below about implementation > possibility or is the incoming data already using named graphs? > I only wrote "groups of triples" because I wanted to make sure that representing them each in their own graph was a sensible thing to do. You're right - my thoughts on how it could be solved were all about NGs. The data isn't currently segregated into many graphs, but it'd be relatively trivial to change this in our UC, so for my questions in this thread we can assume they are already each in their own NG. What I forgot to mention was that, in the case of (a) or (b) from above, I am imagining the querying would happen against the union graph such that clients don't need to know what the graphs are which they are allowed to see. (Hence attempt
Re: Dynamically restricting graph access at SPARQL query time
Hi Martynas, Thank you very much for the suggestion (and additional information out-of-band). I've been having a look at LinkedDataHub and will come back to you with some questions, if you don't mind. Regards, Vilnis On Fri, 21 Jan 2022 at 15:26, Martynas Jusevičius wrote: > > WebAccessControl ontology might be relevant here: > https://www.w3.org/wiki/WebAccessControl > We're using a request filter that controls access against > authorizations using SPARQL. > > On Fri, Jan 21, 2022 at 4:13 PM Vilnis Termanis > wrote: > > > > Hi, > > > > For a SPARQL query via Fuseki, we are trying to restrict visibility of > > groups of triples (each with multiple subjects) dynamically, in order > > to allow for generic queries to be executed by users (instead of > > providing tinned ones). > > > > Looking at the available ACL mechanisms in Jena/Fuseki, I assume > > storing each of these groups as a distinct graph might be the way > > forward. (The expectation is to be able to support 10^5 or higher > > number of these.) > > > > I.e.: Given a user (external to Fuseki, e.g. presented via shiro via > > LDAP/other), only consider triples from the set of graphs 1..N during > > the query. (Where the allowed list of 1..N graphs is to be looked up > > at the point of the query.) > > > > From my limited understanding, some potential routes are: > > > > a) jena-fuseki-access - Filters triples at storage level via "TDB Quad > > Filter" support in TDB. > > However, the configuration of allowed graphs per user is static at runtime. > > > > b) jena-permissions - Extends the SPARQL query engine with an Op > > rewriter which allows a user-defined evalulator implementation to > > allow/deny access to a graph/triple, given a specific user/principle. > > (The specific yes/no evaluation responses are cached for the duration > > of a query/operation.) > > However, this can only applied to a single graph as it stands. > > > > c) Parse & re-write the query to e.g. scope it using a fixed set of > > "FROM" clauses. From some minimal testing (with ~200 FROM clauses) > > this does not appear to perform well (compare to a tinned query which > > explicitly restricts access via knowledge of the ontologies involved). > > I appreciate that maybe having a large list of FROM clauses is an > > anti-pattern. > > > > My questions are: > > > > 1) Does filtering to a set of subset of graphs (from a large set of > > graphs) to restrict access sounds like a sensible thing to do? (Note > > that each of these graphs would contain a set of multiple subjects - > > i.e. we are not trying filter by specific predicate/object values.) > > > > 2) Would extending either jena-fuseki-access to support the > > user-graph-list lookup dynamically OR extend jena-permissions to work > > at dataset level be sensible things to do? > > > > 3) If the answer to either of (2) is yes - I'd be interested in > > getting a better understanding of what would be involved to gauge the > > size/effort of such an extension. I have had a look codebases for the > > aforementioned projects, but my knowledge of TDB/ARQ/etc is very > > limited. (We'd potentially be interested in taking this on, time & > > priorities permitting.) > > > > I didn't know which mailing list to send this to but I thought the > > users list would probably be a better starting point. > > > > Regards, > > Vilnis > > > > -- > > Vilnis Termanis > > Senior Software Developer > > > > e | vilnis.terma...@iotics.com > > www.iotics.com -- Vilnis Termanis Senior Software Developer m | +44 (0) 7521 012309 e | vilnis.terma...@iotics.com www.iotics.com The information contained in this email is strictly confidential and intended only for the parties noted. If this email was not intended for your use, please contact Iotics. For more on our Privacy Policy please visit https://www.iotics.com/legal/
