[foaf-dev] foaf phone and tel URLs

[Peter Williams]

		Given a URI, a system may attempt to perform a variety of operations on the resource, as might be characterized by words such as "access", "update", "replace", or "find attributes". Such operations are defined by the protocols that make use of URIs, not by this specification. However, we do use a few general terms for describing common operations on URIs. URI "resolution" is the process of determining an access mechanism and the appropriate parameters necessary to dereference a URI; this resolution may require several iterations. To use that access mechanism to perform an action on the URI's resource is to "dereference" the URI.
		 
		...

		Although many URI schemes are named after protocols, this does not imply that use of these URIs will result in access to the resource via the named protocol. URIs are often used simply for the sake of identification. Even when a URI is used to retrieve a representation of a resource, that access might be through gateways, proxies, caches, and name resolution services that are independent of the protocol associated with the scheme name. The resolution of some URIs may require the use of more than one protocol (e.g., both DNS and HTTP are typically used to access an "http" URI's origin server when a representation isn't found in a local cache).

		http://gbiv.com/protocols/uri/rfc/rfc3986.html#identification

 
That a resolvable tel: is dependent on a SS7 nameserver or an ENUM nameservice (and then their feature/sub-service naming/addressing properties) seems consistent with W3C doctrine, no?
 
With lots of help from RDF/OWL experts, I've been playing with mapping metadata of an existing and relatively simply name resolution (http) service into a RDF vocab on the fly. Why would FOAF/SemWeb not do the same to uri with a tel scheme - which instance may be dependent on contextual name servers for its semantics? For example: evaluation/resolution of a tel URI in the context of FOAF might cause the evaulator to perform a metadata mapping against the SS7/ENUM name[space] resolvers - in the context associated with the particular tel:... . Providing the dynamic-ontology of that sub-resolution protocol is added to the FOAF-processor's inferencing rulebase, surely then the evaluator has (dynamic and late-bound) semantics for a tel:... that are are at least well-defined in RDF Semantic terms (even tho they are managed by non-SebWeb conforming entities)
 
I think we saw this also last week, when someone proposed dynamically generating FOAF stream from an openid XRD - a set of service endpoints associated with a re-named (openid) identifer. As XRDs have their own extensiblity mechanism, an evaluator of the FOAF stream really needs help - to dynamically learn (from some rulebase stored in the FOAF stream, perhaps) the (dynamic) RDF vocab - generated to assist the ultimate processor interpret those extensions in the underlying (non-RDF) data source.

 
________________________________

From: foaf-dev-bounces at lists.foaf-project.org on behalf of Story Henry
Sent: Wed 1/30/2008 10:03 AM
To: Friends Friend of a
Subject: [foaf-dev] foaf phone and tel URLs



I was reading the tel: spec
http://www.ietf.org/rfc/rfc2806.txt

It looks like their definition of a tel URI is context dependent in 
many cases. Ie. that is not what I would call a URI, understood as a 
Universal Resource Identifier. Of course some people want to think 
that URIs are "Uniform Resource Identifiers", but well that breaks a 
lot of web conventions. If one has to take the context of where a URI 
is asserted into account to understand its meaning, then it is not 
very useful in any setting where information needs to be merged, most 
of all the semantic web.

Should we limit the tel URIs of foaf:phone to ones that are Universal, 
ie useable from anywhere on the planet? Or should one specify an 
indirection context:

:me foaf:phone [ from [ geo :France ];
                 call "0164225952";
               ],
               [ from [ geo :IbisHotel ];
                 call "9164225952";
               ] ...

No, I don't really want to spend time right now thinking about this. 
Perhaps the vcard people have. It may be worth a note... Sorry if this 
has already been discussed before.

        Henry

Home page: http://bblfish.net/