incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spicar <daniel.spi...@trialox.org>
Subject Re: Clerezza VS Jena Schemagen (Re: SchemaGen: How to use with "path based" ontologies)
Date Wed, 26 Oct 2011 14:55:12 GMT
Jena schemagen works with path based ontologies. It handles the names simply
by just resolving the last path component.

For an ontology on namespace: http://s.opencalais.com/1/type

it will create constants like:
public static final Resource City = m_model.createResource( "
http://s.opencalais.com/1/type/em/e/City" );
public static final Resource Electronics = m_model.createResource( "
http://s.opencalais.com/1/type/er/Product/Electronics" );

etc.

Notice how the Resources are in different sub-namespaces.
When they face Resource names that are not unique, e.g.:

http://s.opencalais.com/1/type/em/e/City and
http://s.opencalais.com/1/type/er/Geo/City

They create names constant like:
public static final Resource City = m_model.createResource( "
http://s.opencalais.com/1/type/em/e/City" );
public static final Resource City_CLASS = m_model.createResource( "
http://s.opencalais.com/1/type/er/Geo/City" );
public static final Resource City_CLASS1 = ...
public static final Resource City_CLASS2 = ...

Well I don't really like the handling of name clashes but otherwise it is
probably pretty straight forward. The difficulty is that you'd need at least
some java doc documentation of the constants to be able to distinguish the
different City instances, but jena does not generate that.


On Thu, Oct 20, 2011 at 9:13 PM, Florent André <florent@apache.org> wrote:

> Cristal clear as usual thanks Reto !
>
> ++
>
>
> On 10/20/2011 04:39 PM, Reto Bachmann-Gmür wrote:
>
>> Hi Florent,
>>
>> Well the most obvious difference is that Schemagen creates Jena
>> properties and resources and the clerezza one for the clerezza api.
>> Otherwise the tools have the same goal, not sure if the jena version
>> integrates as a plugin into maven.
>>
>> Certainly worth having a look at the Jena tool to see how they deal
>> with those hard-to-name properties/classes.
>>
>> Cheers,
>> Reto
>>
>> On Thu, Oct 20, 2011 at 11:30 AM, florent andré
>> <florent.andre-dev@4sengines.com>  wrote:
>>
>>> Hi,
>>>
>>> Read this discussion, understand what append, search a little bit... and
>>> found 2 schemagen (apparently not linked) :
>>> - jena : http://jena.sourceforge.net/how-to/schemagen.html
>>> - clerezza :
>>>
>>> http://svn.apache.org/repos/asf/incubator/clerezza/trunk/parent/rdf.schemagen/src/main/java/org/apache/clerezza/rdf/schemagen/
>>>
>>> What about differences, similarities,...
>>>
>>> Thanks.
>>>
>>>
>>> On 10/18/2011 09:46 AM, Daniel Spicar wrote:
>>>
>>>>
>>>> Hi clerezza people,
>>>>
>>>> I ran into an issue with SchemaGen. I tried to create a Java class
>>>> representing the Calais Ontology (
>>>>
>>>>
>>>> http://www.opencalais.com/files/OpenCalaisLinkedDataSchema_R4_Jan09.rdfs_.txt
>>>> ).
>>>> The problem is, that the Ontology uses paths instead of fragment
>>>> identifiers
>>>> to identify and classify different "types", "entities", etc.
>>>>
>>>> e.g.:
>>>> http://s.opencalais.com/1/type/em/e/Anniversary
>>>> http://s.opencalais.com/1/type/er/Company
>>>> http://s.opencalais.com/1/type/er/Geo/City
>>>>
>>>> Now SchemaGen needs me to declare the Ontology like this:
>>>> <owl:Ontology rdf:about="http://s.opencalais.com/1/" />
>>>>
>>>> But this won't work, because SchemaGen fails to generate java constants
>>>> from
>>>> paths, e.g. it won't be able to create a constant from
>>>> type/em/e/Anniversary.
>>>> Therefore I need to declare the ontology for each different subpath like
>>>> this:
>>>> <owl:Ontology rdf:about="http://s.opencalais.com/1/type/em/e/" />
>>>> <owl:Ontology rdf:about="http://s.opencalais.com/1/type/er/" />
>>>> <owl:Ontology rdf:about="http://s.opencalais.com/1/type/er/Geo/" />
>>>>
>>>> And I need to do this in 3 different files.
>>>>
>>>> This is pretty annoying. Is there any way to circumvent this?
>>>>
>>>> If not, what would be a clever way to avoid this problem? I assume the
>>>> problem stems from SchemaGen trying to create Java Constants with
>>>> slashes
>>>> in
>>>> their names which I assume is illegal. We could do a simple solution of
>>>> using some other character in this case (e.g. "_"). But does anyone have
>>>> an
>>>> idea how to solve this issue in a nicer way?
>>>>
>>>> Daniel
>>>>
>>>>
>>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message