# Re: URIs for great circle arcs

From: Toby A Inkster <tai@g5n.co.uk>
Date: Mon, 22 Jun 2009 17:03:16 +0100
Message-Id: <FBCAE6A1-287F-4FE2-842E-4AB4154B335A@g5n.co.uk>
To: Peter Coetzee <peter@coetzee.org>
```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

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