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-tallest-outdoor-seated-bronze-buddha.rdf
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-tallest-outdoor-seated-bronze-buddha#placemark
- the web page URI: http://www.tagcrumbs.com/Sebastian/placemarks/big-buddha-world-s-tallest-outdoor-seated-bronze-buddha
- 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-galway-stopover
[3] http://www.tagcrumbs.com/cornelius/placemarks/deri-digital-enterprise-research-institute
[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-kleistpark
[7] http://www.w3.org/2003/01/geo/wgs84_pos#
[8] http://rdfs.org/sioc/spec/
--
Cornelius Rabsch | www.tagcrumbs.com/cornelius | www.inperspektive.com