Hi, Andy,
Can you please help me to get some ideas about how to query for the values that
are related to the the specified item (like cim:SynchronousMachine).
As you can see, there is not returning for aVal (cim:AnalogValue.value --- I
want to query these values related to cim:Measurement.PowerSystemResource).
Actually, I do not know how to do this kind of SPARQL query. I just put
'somethings' (colored with light green) tried to query aVal
(cim:AnalogValue.value).
CAN YOU PLEASE tell me what will be the CORRECT SPARQL query
get cim:AnalogValue.value? Thanks a lot!
Cheers,
Frank
See the followings for more details.
The result of this SPARQL query:
{
"head": {
"vars": [ "id" , "name" , "bVol" , "aVal" ]
} ,
"results": {
"bindings": [
{
"id": { "type": "uri" , "value":
"file:///C:/Users/yyy/work/bbb/core/resources/rdfs/IEEE118_CIM15_MEAS.xml#_048aea70-c766-11e1-8775-005056c00008"
} ,
"name": { "type": "literal" , "value": "Sporn SM" } ,
"bVol": { "type": "literal" , "value": "132" }
} ,
{
"id": { "type": "uri" , "value":
"file:///C:/Users/yyy/work/bbb/core/resources/rdfs/IEEE118_CIM15_MEAS.xml#_047fc6e6-c766-11e1-8775-005056c00008"
} ,
"name": { "type": "literal" , "value": "Pinevlle SM" }
} ,
{
"id": { "type": "uri" , "value":
"file:///C:/Users/yyy/work/bbb/core/resources/rdfs/IEEE118_CIM15_MEAS.xml#_04839777-c766-11e1-8775-005056c00008"
} ,
"name": { "type": "literal" , "value": "Tidd SM" } ,
"bVol": { "type": "literal" , "value": "132" }
} ,
{
"id": { "type": "uri" , "value":
"file:///C:/Users/yyy/work/bbb/core/resources/rdfs/IEEE118_CIM15_MEAS.xml#_04859346-c766-11e1-8775-005056c00008"
} ,
"name": { "type": "literal" , "value": "Philo SM" } ,
"bVol": { "type": "literal" , "value": "132" }
}
As you can see, there is not returns for aVal. Actually, I do not know how to
do this kind of SPARQL query. I just put 'somethings' (colored with light
green) tried to query aVal (cim:AnalogValue.value).
CAN YOU PLEASE tell me what will be the CORRECT SPARQL query for it? Thanks.
Cheers,
Frank
./s-query --service http://ipaddr:3030/dataset/query 'PREFIX cim:
<http://iec.ch/TC57/2010/CIM-schema-cim15#> select ?id ?name ?bvId ?res
?analog ?analogValue ?id2 ?aVal WHERE {GRAPH
<http://xxx.com/graphs/yyy/berkeley/12.0/20120914152504>{
?id a cim:SynchronousMachine; cim:IdentifiedObject.name ?name. OPTIONAL {?id
cim:ConductingEquipment.BaseVoltage ?bvId. ?bvId cim:BaseVoltage.nominalVoltage
?bVol} OPTIONAL {?id2 cim:Measurement.PowerSystemResource ?res . ?res
cim:Analog ?analog . ?analog cim:AnalogValue.Analog ?analogValue . ?analogValue
cim:AnalogValue.value ?aVal . } } } '
<cim:AnalogValue rdf:ID="_8672158A46976A9BC32EAB365A190703">
<cim:AnalogValue.value>-252</cim:AnalogValue.value>
<cim:AnalogValue.Analog rdf:resource="#_8C55B894578EA96D44DEC9A318898ABC"/>
</cim:AnalogValue>
<cim:Analog rdf:ID="_8C55B894578EA96D44DEC9A318898ABC">
<cim:IdentifiedObject.name>MW</cim:IdentifiedObject.name>
<cim:Measurement.unitMultiplier
rdf:resource="http://iec.ch/TC57/2010/CIM-schema-cim15#UnitMultiplier.M"/>
<cim:Measurement.unitSymbol
rdf:resource="http://iec.ch/TC57/2010/CIM-schema-cim15#UnitSymbol.W"/>
<cim:Measurement.PowerSystemResource
rdf:resource="#_044cd00a-c766-11e1-8775-005056c00008"/>
<cim:Measurement.Terminal
rdf:resource="#_045e5c30-c766-11e1-8775-005056c00008"/>
<cim:Measurement.measurementType>ThreePhaseActivePower</cim:Measurement.measurementType>
</cim:Analog>
<cim:SynchronousMachine rdf:ID="_044cd00a-c766-11e1-8775-005056c00008">
<cim:IdentifiedObject.name>Glen Lyn SM</cim:IdentifiedObject.name>
<cim:Equipment.EquipmentContainer
rdf:resource="#_04765109-c766-11e1-8775-005056c00008"/>
<cim:ConductingEquipment.BaseVoltage
rdf:resource="#_0460a620-c766-11e1-8775-005056c00008"/>
<cim:RegulatingCondEq.RegulatingControl
rdf:resource="#_045beb36-c766-11e1-8775-005056c00008"/>
<cim:SynchronousMachine.minQ>-50</cim:SynchronousMachine.minQ>
<cim:SynchronousMachine.type
rdf:resource="http://iec.ch/TC57/2010/CIM-schema-cim15#SynchronousMachineType.generator"/>
<cim:SynchronousMachine.GeneratingUnit
rdf:resource="#_044f6819-c766-11e1-8775-005056c00008"/>
<cim:SynchronousMachine.operatingMode
rdf:resource="http://iec.ch/TC57/2010/CIM-schema-cim15#SynchronousMachineOperatingMode.generator"/>
<cim:SynchronousMachine.maxQ>155</cim:SynchronousMachine.maxQ>
</cim:SynchronousMachine>
+++
________________________________
From: Andy Seaborne <[email protected]>
To: [email protected]
Sent: Monday, November 12, 2012 9:21 AM
Subject: Re: TDB Dataset.commit
On 12/11/12 13:04, "Dr. André Lanka" wrote:
> Hi Andy,
>
> thanks for your answer. I really missed 0.9.4. You are right, the issues
> vanished with the new version. Thanks for the hint.
>
> By the way: We're just patching 0.9.4 to provide a global cache (for
> both reading and writing) for both Nodes and Blocks in direct file mode.
> This means that all tdb stores share this one big LRU cache.
>
> By this we can easily read and write to thousands of stores in parallel.
> Without theses changes we are unable to use more than 200 stores in one
> jvm (OOME on a 2GB jvm).
> Perhaps it may be an interesting option to integrate our changes to the
> official tdb branch.
Yes - that would be interesting. The nest step would be to open an JIRA
for discussion and attaching patches.
It might be better to use that as the default option if the performance
impacts are not too great.
> Of course the performance for a single store is slightly worse than your
> implementation, but it allows one to have more stores on the same
> machine (we have 4,500 on each).
> A configuration parameter could control the behaviour of the factories
> to use the one or the other approach.
Is each store using named graphs? Or is one store, one graph?
TDB support dynamic query to pick a subsets of the graphs out of a
potentially large pool of graphs [1]. If the choice of graph is exposed
at the API, not just in FROM / FROM NAMED (it may already be there but
with context magic), one dataset can server many graphs with query on
one graph at a time.
Andy
[1] http://jena.apache.org/documentation/tdb/dynamic_datasets.html
>
> Greetings
> André
>
>
> This could be also useful for other users that use plenty of TDB
> stores in parallel.
>
> On 06.11.2012 21:53, Andy Seaborne wrote:
>> Have you tried version 0.9.4?
>>
>> It has fixes that may apply to your situation.
>>
>> Andy
>>
>>
>> On 06/11/12 08:33, "Dr. André Lanka" wrote:
>>> Hello (once more),
>>>
>>> the problem could be fixed by doing the following:
>>>
>>> BlockMgrJournal: Add "blockMgr.sync();" to sync()
>>> NodeTableTrans: Add "base.sync();" to sync()
>>>
>>> Yet, I don't know what side effects this would have. Could some of the
>>> tdb specialists judge these changes?
>>>
>>> Best wishes
>>> André
>>>
>>>
>>> On 06.11.2012 08:52, "Dr. André Lanka" wrote:
>>>> Hello TDB developers
>>>>
>>>> thanks for you great work :)
>>>>
>>>> Unfortunately, I encountered some problems while testing TDB 0.9.3. It
>>>> turned out that a dataset.commit() doesn't force NodeTableNative to
>>>> write the whole data to disk or that NodeTableNative.syncNeeded wasn't
>>>> set properly earlier.
>>>>
>>>> By this, tdb stores can get broken even if no write transaction is
>>>> active if the jvm crashes. (The other files seem to be written fine,
>>>> but
>>>> nodes.dat misses some information)
>>>>
>>>> Is there a simple work-around for this problem (Simpler than patching
>>>> NodeTableNative)? Closing the store would help but is not feasible for
>>>> us.
>>>>
>>>>
>>>> Thanks in advance
>>>> André
>>>>
>>>
>>
>
