Re: ODRL enforcement implementation

Both (is more complicated than that), and the actual path is contextual to the constraint's LeftOperand's shape (which is known at the evaluation point).

So you don't go down a rabbit hole - I don't use "SPARQL that explicitly checks types or classes" as that won't scale.

Regards,

___________________________________
Joshua Cornejo
marketdata <https://www.marketdata.md/>
embed open standards 
across your supply chain

On 30/09/2024, 14:39, "Harshvardhan J. Pandit" <me@harshp.com> wrote:

    Thanks (also for the quick reply) - I will follow up after talking to 
    Beatriz about this.
    For the moment, I'm curious about your interpretation of odrl:isA - e.g. 
    do you check rdf:type or rdfs:subClassOf?
    
    - Harsh
    
    On 30/09/2024 14:36, Joshua Cornejo wrote:
    > Hi,
    > 
    > We can have a chat, but as a summary, to achieve practical efficiency, I do take steps before evaluation, otherwise, traversing the networks to fetch, parse, and build becomes a burden.
    > 
    > In the case Beatriz has -  https://github.com/w3c/odrl/issues/28 - I can evaluate both: odrl:eq to an instance of something (under 1ms), or odrl:isA part of a taxonomy or a graph of the same class of elements (first time depends, but following times under 1ms).
    > 
    > Regards,
    > ___________________________________
    > Joshua Cornejo
    > marketdata <https://www.marketdata.md/>
    > embed open standards
    > across your supply chain
    > 
    > On 30/09/2024, 14:25, "Harshvardhan J. Pandit" <me@harshp.com> wrote:
    > 
    >      Hi Joshua.
    >      Off-topic from the thread - can I see your implementation of odrl:isA?
    >      More specifically, I'm interested in how this issue is being dealt with
    >      in practice: https://github.com/w3c/odrl/issues/28 i.e. how to check
    >      when the value can be any of: instance, subclass, or skos:broader/narrower
    >      
    >      Regards,
    >      Harsh
    >      
    >      On 30/09/2024 12:53, Joshua Cornejo wrote:
    >      > I have already implemented the three I considered most taxing (odrl:isA,
    >      > odrl:hasPart, and odrl:isPartOf) the following 3 (odrl:isAllOf,
    >      > odrl:isAnyOf, odrl:isNoneOf) are simpler to calculate within the
    >      > constraint, and the final 6 are the easiest.
    >      
    >      --
    >      ---
    >      Harshvardhan J. Pandit, Ph.D
    >      Assistant Professor
    >      ADAPT Centre, Dublin City University
    >      https://harshp.com/
    >      
    >      
    > 
    > 
    
    -- 
    ---
    Harshvardhan J. Pandit, Ph.D
    Assistant Professor
    ADAPT Centre, Dublin City University
    https://harshp.com/

Received on Monday, 30 September 2024 13:45:37 UTC