Re: URIs for great circle arcs

On 22 Jun 2009, at 08:52, Peter Coetzee wrote:

> First off - the whole "infinite set of points" Container is a tough  
> one to swallow, without nasty URI-hacking to suggest a resolution  
> for how many points you want to see, etc.

Essentially I was debating two ways of representing an arc:

1. A subclass of geo:SpatialThing - a single discrete "place" which  
is very long but infinitely thin; or
2. A subclass of rdfs:Container - essentially an infinitely big  
collection of infinitely small points.

Both are useful ways of thinking of an arc with advantages and  
disadvantages. In the end I decided to define, and a one-to-one  
mapping between then (the arc:points property).

I've since come up with a third way I could have done it:

3. A subclass of rdfs:Class - such that all geo:Point resources along  
the arc have the arc as an rdf:type.

Though this third way offers no way of conferring directionality onto  
the arc. Directionality is important. If the arc from A to B is the  
owl:sameAs the arc from B to A, then you can't give a definitive  
answer to the question of what bearing it has.

> I wonder if there's a neat Linked-Data way of doing this, to make  
> it browseable. For example, how about describing those points in  
> terms of the arcs that connect them (caveat: I know little-to- 
> nothing about geodesic arcs!) So, what I'm imagining is that you  
> can describe the arc from A to B via C in terms of the arc from A  
> to C and the arc from C to B, recursively. In this way you can  
> build up a greater resolution of points on the arc without having  
> to URI-hack your way to the solution. Would this even work in this  
> domain?

I've added this. The arc vocab now has a property "part" connecting  
two directed lines and defined so that any point on the object line  
must lie on the subject line.

The data served up now includes "part" links from the requested arc  
to two smaller arcs, joining the ends of the requested arc to its  
midpoint.

> More generally, I'm intrigued by the notion of the slight mix of  
> services you're offering here. On the one hand is a really-quite- 
> cool "linked data great circle arc" service. On the other, there's  
> the ability for the user of the service to essentially perform a  
> mesh-up (or is this a mash-up? I get confused ;)) of this data with  
> any other service. Are these safe to mix? Is it desirable to let  
> the user "puppet" my mouth to say anything they wish?

I'm using "geo:" URIs to describe points because they're very easy to  
construct, for any point on the earth's surface, at any desired  
precision. (In fact, geo allows for altitude to be provided, but that  
significantly complicates the mathematics, so I don't use this  
feature.) Sadly, they're not easily dereferencable, so I thought it  
would be useful to provide a way for people to paste in their own  
more linked-dataish URIs.

Yes, this results in possible trust issues. In the RDF/XML document I  
assert that I am the document's foaf:maker. Fools who decide to trust  
my data blindly could be lulled into believing that Tokyo's in the  
middle of the Surrey countryside, a mere 20 miles or so from London.

Perhaps I should list myself as the mere dc:publisher of the  
information, but (even when people paste in their own URLs), I do  
consider myself the primary creator of the information.

What I really want to indicate though is whether or not I believe the  
information that I am, myself, providing.

	<> foaf:maker ?x ; ex:isBelievedBy ?x .

versus:

	<> foaf:maker ?x .

We really need a good vocabulary for describing the trust agents have  
for documents, and trust levels between agents themselves. I've  
talked about that in #swig before, and have suggested it as a  
possible VoCamp Bristol 2009 project.

There is some good work at <http://trust.mindswap.org/trustOnt.shtml>  
and <http://daml.umbc.edu/ontologies/webofbelief/1.4/wob.owl> but I  
don't think either of them is quite right. The former seems to  
confuse trust and agreement too much, and only talks about trust  
between agents, whereas the latter is overcomplicated, and only talks  
about agents trusting RDF graphs.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Monday, 22 June 2009 16:03:06 UTC