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:[email protected]>
<http://tobyinkster.co.uk>
