Tagcrumbs is about social placemarking, so we are having people and  
placemarks. The focus will be on the placemarks and its exact and  
detailed representation in triples and not about the users, the social  
network or the linking of placemarks by distance or nearby criteria.

Let's consider some sample placemarks (add .rdf for RDF/XML): a note  
about an event [2], a research institute [3], a restaurant [4], a  
construction [5] or a story [6]. The common thing is the location and  
an annotation which can be from a variety of topics (thinking  
sioc:topic). So we cannot automatically conclude what the topic is  
without additional reasoning (maybe using (machine/system) tags).

Sample RDF:
http://www.tagcrumbs.com/Sebastian/placemarks/big-buddha-world-s-tall...
It can be outdated and the next deploy contains the RDF/XML I describe  
here.

Notes for the placemark representation:

URIs:
        - the concept of a placemark is identified by URI: http://www.tagcrumbs.com/Sebastian/placemarks/big-buddha-world-s-tall...
        - the web page URI: http://www.tagcrumbs.com/Sebastian/placemarks/big-buddha-world-s-tall...
         - the creator concept URI: http://www.tagcrumbs.com/
Sebastian#me
         - the creator profile page URI: http://www.tagcrumbs.com/Sebastian

A placemark is a wgs84_pos:SpatialThing [7] and its predicates common  
ones from FOAF, Dublin Core or W3C Geo.
To support SIOC [8] I think it is good idea to add a sioc:Post class  
and some sioc predicates as well? I focused on using common  
vocabularies and not introducing new terms to model more application  
specific things like copied/nearby/recommended, for example.

The location of a placemark is described via geo:lat/geo:long.

A geonames:Feature class for the city assigned by the user to the  
placemark will be added and linked via foaf:based_near. We prefer  
manageable redundancy to have a complete data set that is easier to  
link to other data sources. This also guarantees that internal SPARQL  
queries keep consistent with the Geonames dump we use.
Redundancy also makes the life of third-party developers easier, less  
requests and consistent access.

foaf:maker (http://xmlns.com/foaf/spec/#term_maker) will be added.

An auto discovery link will be added to the web page once there is  
agreement about the RDF representation.
<link rel="meta" type="application/rdf+xml" title="RDF" href="@@URL of  
RDF info about this placemark" />

Feedback is appreciated also with regards to possible use cases for  
linking other data sources with geospatial content. There are many  
more things to discuss but this should be fine for a first draft.

What is the best way to model the tag relationship for placemarks in  
RDF?

Regards,
  Cornelius.

[1] http://en.wikipedia.org/wiki/Resource_Description_Framework
[2] http://www.tagcrumbs.com/cornelius/placemarks/volvo-ocean-race-2009-g...
[3] http://www.tagcrumbs.com/cornelius/placemarks/deri-digital-enterprise...
[4] http://www.tagcrumbs.com/Ben/placemarks/chez-georges
[5] http://www.tagcrumbs.com/Ben/placemarks/tour-eiffel
[6] http://www.tagcrumbs.com/Ben/placemarks/papaya-thai-cuisine-am-kleist...
[7] http://www.w3.org/2003/01/geo/wgs84_pos#
[8] http://rdfs.org/sioc/spec/