- From: Toby A Inkster <tai@g5n.co.uk>
- Date: Mon, 22 Jun 2009 17:03:16 +0100
- To: Peter Coetzee <peter@coetzee.org>
- Cc: Linked Data community <public-lod@w3.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 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