Hi Dave,
thanks a lot, your queries are working perfectly - now that I know the
principle I will try to implement other queries.
Best regards,
Bojan
On Wed, Mar 6, 2013 at 9:57 AM, Dave Reynolds <dave.e.reyno...@gmail.com>wrote:
> Hi Bojan,
>
>
> On 06/03/13 06:30, Bojan Milić wrote:
>
> What I would like to achieve is to build some kind of document library,
>> where some documents use and create other documents.
>>
>
> OK, so in fact it seems like you mostly want to create and query data.
> That's fine, that's what many people use Jena for.
>
> The ontology could be used to declare some of the shape of your data
> (domain, ranges) but given the wackiness of OWL semantics it probably isn't
> going to help you that much.
>
> [Example data snipped.]
>
> *What would I like to achieve:*
>>
>> 1. Select * from model where hasLevel = 1 (I would like to get all
>> individuals that are on level 1, level2, etc)
>>
>
> Easy. The programmatic way to do queries like this looks something like:
>
> String prefixes = "PREFIX ns: <" + baseURI + "> ";
> String query = prefixes + "SELECT * WHERE {?i ns:hasLevel 3}";
> QueryExecution qe
> = QueryExecutionFactory.create(**query, processModel);
> try {
> ResultSetFormatter.out(System.**out, qe.execSelect());
> } finally {
> qe.close();
> }
>
> Though I normally have various helper classes to cut down on the verbosity
> and typically centralize prefix management.
>
> For me, on your data, this produces:
> ------------------------------**------------------------------**
> ------------------------------**-----
> | i |
> ==============================**==============================**
> ==============================**=====
> | <http://jena.hpl.hp.com/**example#P1_4_**EstablishAndCommunicateSupplyC*
> *hainPlans<http://jena.hpl.hp.com/example#P1_4_EstablishAndCommunicateSupplyChainPlans>>
> |
> | <http://jena.hpl.hp.com/**example#P1_3_**BalanceSupplyChainResourcesWit*
> *hSCRequirements<http://jena.hpl.hp.com/example#P1_3_BalanceSupplyChainResourcesWithSCRequirements>>
> |
> | <http://jena.hpl.hp.com/**example#P1_2_**IdentifyPrioritizeAndAggregate*
> *SupplyChainResources<http://jena.hpl.hp.com/example#P1_2_IdentifyPrioritizeAndAggregateSupplyChainResources>>
> |
> | <http://jena.hpl.hp.com/**example#P1_1_**IdentifyPrioritizeAndAggregate*
> *SupplyChainRequirements<http://jena.hpl.hp.com/example#P1_1_IdentifyPrioritizeAndAggregateSupplyChainRequirements>>
> |
> ------------------------------**------------------------------**
> ------------------------------**-----
>
>
> 2. All individuals have some meta data, like: title, description, metric,
>> etc. I am still not sure how to achieve that. So i have 4 classes that
>> have
>> all my individuals inside. These have to share same metadata. How would
>> you
>> do this?
>>
>
> Where suitable vocabularies exist then just use them. For example:
>
> P1_PlanSupplyChain
> .addProperty(RDFS.label, "Plan supply chain")
> .addProperty(DCTerms.title, "A plan supply chain")
> .addProperty(DCTerms.**description, "I am a supply chain plan");
>
> Where they don't (metric) then create additional properties in your
> ontology or in another ontology.
>
> If you want to say that everything in each of your classes should have all
> of these then you could group them under some common Document class and use
> OWL to provide the cardinality constraints on the properties.
>
> However, the whole "open world" thing means that such declarations are not
> necessary. You can always just add properties to things. When you want to
> validate then OWL semantics are less that useful so validation is often
> done using queries instead.
>
>
> 3. I would like to select specific document (individual) and know what is
>> its input / output (uses / creates). So something like this: select * from
>> model where hasLevel = 1 and name='nameOfIndividual' and uses='uses'
>>
>
> Since each individual may or may not have links to others then when search
> use optionals, for example:
>
> SELECT * WHERE {
> ?i ns:hasLevel 3.
> OPTIONAL {?i ns:uses ?uses}
> OPTIONAL {?i ns:creates ?creates}
> }
>
> You can also use
>
> DESCRIBE <uri-for-individual>
>
> to see all the properties for a specific resource.
>
>
> 4. Each individual can consist of some other individual (document) and can
>> create some other individual (document)
>>
>
> Fine.
>
> *Now my question :)*
>>
>> 1. Is this way right at all? As I said I am pretty new to semantic so I
>> am struggling with it, it is totally different concept of what I am used
>> to
>>
>
> Seems OK.
>
> The main advice I'd give would be to separate your ontology (declaration
> of classes and properties, together with any associated constraints) from
> your data.
>
> A common pattern is:
> - create the ontology once, could be in code but equally just using an
> editor, this documents your domain model so you and others can understand it
> - ideally publish the ontology at the URI you have given it, but this is
> not necessary in order to work with it
> - use schemagen (see Jena documentation) to create a java vocabulary
> file to make it easy to refer to the ontology terms in code
> - write code to create instance data (can use OntModel or plain Model)
> referring to that vocab and to store, query etc data as needed
> - if you want to validate your data as being consistent with your
> ontology and *if* the semantics of OWL are useful for this (that's a big
> *if*) then you can create an OntModel which imports your ontology and your
> instance data and use validate() on that with a suitable reasoner
> if you want closed world checking (e.g. you want to say every document
> should have a title and would like checker that tells you when titles are
> missing) then validate() won't help you, instead do this in queries or code
> - those queries can be auto-created from your ontology declarations though
> Jena doesn't have a packaged utility to do that. The Eyeball checker can do
> some forms of validation which may more may not be useful for you.
>
> Dave
>
>
>
>
--
Lep pozdrav,
Bojan Milić
