individuals rdf/xml rendering issue

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

individuals rdf/xml rendering issue

David Torres-4
Hello, I've tried a tool (Schemagen, Jena) to generate Java classes from RDF/XML rendering of my ontology.

The translation runs ok, but some individuals are not defined to "belong" to one type. I analysed the problem and I've founded the following problem on P4 rendering.

 <!-- http://ssiti.uv.es/ontologia/datex2.owl#RoadSideAreaOpened -->

    <owl:Thing rdf:about="#RoadSideAreaOpened">
        <rdf:type rdf:resource="#RoadSideAreaState"/>
    </owl:Thing>

    <!-- http://ssiti.uv.es/ontologia/datex2.owl#RoadSideAreaOvercrowded -->

    <RoadSideAreaState rdf:about="#RoadSideAreaOvercrowded">
        <rdf:type rdf:resource="&owl;Thing"/>
    </RoadSideAreaState>

As you can see, first individual is defined ok, but second is weird defined (it's defined backwards!) so parser ignores the type of RoadSideAreaOvercrowded.

Both of these properties were defined at the same time using the same design pattern.

If I change the definition of second individual (in source code), P4 runs without problems and the user view is still the same. The problem is I have lots of these changes so I can't fix all entities!

Any ideas?

Thanks in advance.
David Torres

_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: individuals rdf/xml rendering issue

Nick Drummond
Hi David,

The second piece of rdf is perfectly valid - it is abbreviated RDF.
You can verify this with the w3c RDF validator [1].
Both just mean that the individual has 2 types which is perfectly fine
- RoadSideAreaState and owl:Thing.
The ordering is arbitrary.

Schemagen should be able to handle this - does it require that only
single types are asserted?

Nick

PS There is a bug in p4 - unless asserted, the owl:Thing type
assertion should not be in there when the individual has an asserted
type, but this doesn't affect the validity of the RDF.

[1] http://www.w3.org/RDF/Validator/


2009/7/4 David Torres <[hidden email]>:

> Hello, I've tried a tool (Schemagen, Jena) to generate Java classes from
> RDF/XML rendering of my ontology.
>
> The translation runs ok, but some individuals are not defined to "belong" to
> one type. I analysed the problem and I've founded the following problem on
> P4 rendering.
>
>  <!-- http://ssiti.uv.es/ontologia/datex2.owl#RoadSideAreaOpened -->
>
>     <owl:Thing rdf:about="#RoadSideAreaOpened">
>         <rdf:type rdf:resource="#RoadSideAreaState"/>
>     </owl:Thing>
>
>     <!-- http://ssiti.uv.es/ontologia/datex2.owl#RoadSideAreaOvercrowded -->
>
>     <RoadSideAreaState rdf:about="#RoadSideAreaOvercrowded">
>         <rdf:type rdf:resource="&owl;Thing"/>
>     </RoadSideAreaState>
>
> As you can see, first individual is defined ok, but second is weird defined
> (it's defined backwards!) so parser ignores the type of
> RoadSideAreaOvercrowded.
>
> Both of these properties were defined at the same time using the same design
> pattern.
>
> If I change the definition of second individual (in source code), P4 runs
> without problems and the user view is still the same. The problem is I have
> lots of these changes so I can't fix all entities!
>
> Any ideas?
>
> Thanks in advance.
> David Torres
>
> _______________________________________________
> protege-owl mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>
> Instructions for unsubscribing:
> http://protege.stanford.edu/doc/faq.html#01a.03
>
>
_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03