Matrix URIs (was: Re: Semantic Web Languages)

I'll echo this one back to the semweb list and cc Mark Nottingham, the
source of the Matrix  URIs reference, in the hope he has time to
answer some of the questions (sorry Mark!). I've always had a little
trouble thinking about the non-contradiction between using URIs as
opaque names, and having something potentially meaningful
incorporated, this seems a fairly definitive case.

I must also admit I find the analogies to procedure calls a little
bothersome, seems to run counter to the loose-coupling benefit of
declarative approaches. But having said that, if you bring in the HTTP
method, it's not much of a stretch to map :

GET //moremaps.com/us/ma/cambridge;roads=main;scale=50000

to something like:

PREFIX : <//moremaps.com>

SELECT ?x ?y

FROM <//moremaps.com/us/ma/cambridge>

WHERE {
   ?x :roads "main" .
   ?y :scale "50000" .
}

On 4/3/06, Frank Manola <fmanola@acm.org> wrote:
>
> Danny Ayers wrote:

> > On 3/31/06, John F. Sowa <sowa@bestweb.net> wrote:
> >>     (R1 a b) (R2 c d) (R3 e f) (R4 g h) ...

> > A mail [1]  just showed up in my inbox, referring to Matrix URIs [2],
> > an idea of Tim Berners-Lee's from 1996 and apparently back on the
> > desirable list. Here's an example:
> >
> > [[
> >          //moremaps.com/map/color;lat=50;long=20;scale=32000
> >
> > might be the URL of an automatically generated map.
> > ]]
> >
> > Looks rather n-ary, don'tya think?
> >
> > What did we need XML for again..? ;-)
> >
>
> Well, we didn't *need* XML to do RDF either, did we?  We could always
> have used a notation involving lots of nested parentheses instead,
> clearly such *vastly* superior notation to XML that it's surprising no
> one thought of that before :-)

> About these URIs, let's see:
>
> *  whose definition of, say, "scale" are we using?  or is this always
> the "home" vocabulary (//moremaps.com/scale), and then, how do I mix
> vocabularies?  URIs for the properties would deal with that (but then
> things get longer).
>
> *  if the idea is that the "hierarchical" part of the URI (see
> http://www.w3.org/DesignIssues/MatrixURIs.html) is always the "subject"
> being qualified by the rest, as in this case (the map is being described
> using the attributes "lat", "long", and "scale"), then this is an
> abbreviation of the "triples":
>
> //moremaps.com/map/color lat   50
> //moremaps.com/map/color long  20
> //moremaps.com/map/color scale 32000
>
> right?  Or is something more complicated going on?
>
> *  If the notion of n-tuple to be used *labels* each position in the
> tuple as this one does, rather than relying on position to determine
> which value goes with which attribute, this makes things easier when I
> want to send them around the Web.  Otherwise, I'd need access to the
> definition of the relation in order to determine which was which.  E.g.,
> if I had a tuple (ignoring the need for URIs for the moment) of the form
>
> map(50, 20, 5000)
>
> how do I know that 50 is a lat rather than a long, and 5000 is a scale
> rather than, say, an altitude?  I'd always need to look up the
> definition of the map relation, right?  And suppose I didn't happen to
> have a value for longitude?  map(50,,5000)?
>
> *  any discussion of substituting general n-ary relations for binary
> relations for the RDF application calls for some examination of the
> subject of normal forms in relational database designs, as well as that
> of primary keys, which I will leave for a later day.


[1] http://lists.w3.org/Archives/Public/public-web-http-desc/2006Apr/0000.html
[2] http://www.w3.org/DesignIssues/MatrixURIs.html

--

http://dannyayers.com

Received on Monday, 3 April 2006 22:21:16 UTC