Is the OGC playing with Linked Data?

Comments

2 comments posted
Some questions/critique:   1)

Some questions/critique:
 
1) Why do we need a geometry class if a geometry is stored as a literal?
2) How do we use this model if we want to separately store and query the centre-location, 2D boundary geometry, and full three dimensional geometry of the Washinton monument? Wouldn't it be much simpler if we could just use three different predicates to link the Washinton monument to these three geometries?
3) Why did the OGC choose to throw away all the hard work that Semantic database implementors have put into building and effectively using triple/quad indices? (I.e. by always using the same predicate with any geometry, thus not being able to use a predicate based index when doing gemotry lookups)?
 
 
 

Posted by Gerrit (not verified) on Thu, 2012-08-23 04:13
Hi Gerrit I disccused your

Hi Gerrit

I disccused your comments in the SWG. Matt Perry's input is the following:

1) Why do we need a geometry class if a geometry is stored as a literal?

 A geometry class hierarchy may be useful for entailments based on transitivity of rdfs:subClassOf and for restricting query results to specific geometry types (e.g., find all point geometries for major cities in Europe).

 2) How do we use this model if we want to separately store and query the centre-location, 2D boundary geometry, and full three dimensional geometry of the Washinton monument? Wouldn't it be much simpler if we could just use three different predicates to link the Washinton monument to these three geometries?

 You can use three different predicates for the Washington monument geometries. We intend for users to create appropriate sub properties of geo:hasGeometry to suit their applications. For this example, we could do something similar to the following:

my:centre-location rdfs:subPropertyOf geo:hasGeometry .

my:boundary-geom rdfs:subPropertyOf geo:hasGeometry .

my:3d-geom rdfs:subPropertyOf geo:hasGeometry .

 

my:WashingtonMonument my:centre-location my:geom1 .

my:geom1 geo:asWKT "POINT(...)"^^geo:wktLiteral .

 

my:WashingtonMonument my:boundary-geom my:geom2 .

my:geom2 geo:asWKT "POLYGON(...)"^^geo:wktLiteral .

 

my:WashingtonMonument my:3d-geom my:geom3 .

my:geom3 geo:asWKT "POLYHEDRALSURFACE Z(...)"^^geo:wktLiteral .

 3) Why did the OGC choose to throw away all the hard work that Semantic database implementors have put into building and effectively using triple/quad indices? (I.e. by always using the same predicate with any geometry, thus not being able to use a predicate based index when doing gemotry lookups)?

 Most commercial triple stores (e.g., Oracle, Virtuoso, OWLIM) use datatype indexes to index typed literal values rather than requiring the same predicate for all values of the same type. In such systems, geo:wktLiteral and geo:gmlLiteral are just additional datatypes to index.

 Requiring the same predicate for all geometries seems a bit too restrictive. Also, it is not totally clear how this scheme would work with RDFS and OWL entailment. Would sub properties of the geometry predicate be indexed too?

Posted by Luis Bermudez on Wed, 2012-09-12 13:42