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.
>>>>>>
>>>>>>
>>>>>>
