Thank you Lorenz.
On Wed, Jul 26, 2017 at 3:24 PM, Lorenz Buehmann <
[email protected]> wrote:
> SPARQL 1.1 Update is straightforward ...
>
> General structure for making update queries aka. delete + insert:
>
>
> DELETE {
>
> }
>
> INSERT {
>
> }
>
> WHERE {
>
> }
>
>
> On 26.07.2017 14:04, javed khan wrote:
> > Thank you Dave, Ok I am going to read about the UPDATE statements and how
> > it works to update our owl file.
> >
> >
> >
> > On Wed, Jul 26, 2017 at 2:51 PM, Dave Reynolds <
> [email protected]>
> > wrote:
> >
> >> On 26/07/17 12:07, javed khan wrote:
> >>
> >>> Hello Dave, for instance, if we want to assign players to different
> >>> classes
> >>> i-e Star player or Average player based their goals like if player
> NoGoals
> >>>
> >>>> 10 then ?player rdf:type StarPlayer.
> >>>>
> >>> Can we do it using SPARQL Update?
> >>>
> >> Yes, we've already said that.
> >>
> >> If yes, how?
> >> I think there's some misunderstanding here. We're not going to write
> your
> >> code or rules or queries for you. As volunteers we try to help with
> aspects
> >> of Jena as best we can but the basics of learning Sparql are up to you.
> As
> >> is the design of your data flow, how updates will work and how you
> handle
> >> change.
> >>
> >> Dave
> >>
> >>
> >>
> >>> On Wed, Jul 26, 2017 at 10:26 AM, Dave Reynolds <
> >>> [email protected]>
> >>> wrote:
> >>>
> >>>
> >>>> On 25/07/17 11:57, javed khan wrote:
> >>>>
> >>>> Dave, the "Goal" here is a data property which has integer values. Is
> it
> >>>>> monotonic in this case?
> >>>>>
> >>>>>
> >>>> Presumably that means that when the number of goals change you remove
> the
> >>>> statement with the old data property value and add a replacement
> >>>> statement
> >>>> with a different number. If so then that's the situation I've already
> >>>> described that will work with rules just fine.
> >>>>
> >>>> Try it and see.
> >>>>
> >>>> Lorenz, from past post I have seen some where that if you put the
> >>>> inferred
> >>>>
> >>>>> data into another model, then it may solve the problem. Is this the
> case
> >>>>> or
> >>>>> I have just misinterpret the meaning?
> >>>>>
> >>>>>
> >>>> You have to think through (and if you want help, then describe to us)
> >>>> exactly what the data flow is that you are after. Think of rules as
> just
> >>>> a
> >>>> building block - how you present data to the rules, what you do with
> the
> >>>> resulting inferences and how you handle data changes all depend on the
> >>>> specific problem you are dealing with. Taking the results of inference
> >>>> (the
> >>>> deduction model in the case of forward rules) and copying them
> somewhere
> >>>> else may or may not be helpful depending on exactly what you are
> doing in
> >>>> your overall system.
> >>>>
> >>>> Dave
> >>>>
> >>>>
> >>>> On Tue, Jul 25, 2017 at 10:53 AM, Lorenz Buehmann <
> >>>>
> >>>>> [email protected]> wrote:
> >>>>>
> >>>>>
> >>>>> I know rules are non monotonic,
> >>>>>>> No, that's exactly not the case for Jena rules - the computation is
> >>>>>> monotonic.
> >>>>>>
> >>>>>> We had this discussion here several times, either it was you or some
> >>>>>> other people (e.g. tina sani, kumar rohit etc.) doing the same
> >>>>>> project/exercise/homework whatever
> >>>>>> The answer is, you have to implement it by yourself in the client
> code
> >>>>>> -
> >>>>>> which means you have to remove the data that doesn't hold anymore.
> Or
> >>>>>> you always refer to only the data that will be inferred by the rules
> >>>>>> ad-hoc and don't write it back to the raw data. Indeed this might be
> >>>>>> expensive but we don't know anything about your project. This are
> >>>>>> typical design decision that YOU have to make based on YOUR
> >>>>>> requirements.
> >>>>>>
> >>>>>>
> >>>>>>
>
>
