Re: aboutEachPrefix: possible alternative

Dan,

Thanks for your comments. I'm very glad to see that this might be
interesting.


On Sat, Sep 30, 2000 at 10:11:14AM -0400, Dan Brickley wrote:
> To flesh this out a little:
> 
> In the 'aboutEachPrefix' / PICS tradition, I might want to say that
> every resource whose URI matches http://playboy.com/.*jpg is of rdf:type
> foo:PotentiallyRudePicuture.

Ah - this is where the external selectors come in. I wanted to keep the core
selectors completely based on RFC2396, but some of the first external (or
maybe just non-core, yet still standard) selectors could be:

filename - content of the last path segment, can be used anywhere (doesn't
have the special relationship like path). So, you could do:
  <select type="filename" value="index.htm index.html">
	...
  </select>

extension - any characters after the last period (if present) in the last
path segment (if present).
  <select type="ext" value="jpg jpeg">
	...
  </select>

Of course, these need some refinement, but you get the general drift.


> In other contexts, I might want to create an RDF class
> bar:FriendRelativeOrCoWorker and populate it using an RDF query, so that
> various people (or their mailbox URIs or whatever) are represented as
> being of that rdf:type.

True - I haven't fully considered the implications of this kind of anonymous
reference in RDF (I'm fairly new to RDF, and especially the subtleties, but
IMHO it's obvious that it's a Good Thing). Do you think that this case could
be handed by another type of selector as well?


> In both contexts, I might want to make generic descriptive claims about
> the members of these classes. So mechanisms such as the one you sketch
> might fit into a bigger picture involving other (less URI/regex
> centric) ways of picking out collections of Web resources.

Yes. I focused on URIs because they're the most "real" and apparent way to
identify resources, but it would be good to allow more abstract and
powerful methods as well.

One way to look at this is as a ruleset engine. What's important to cover is
the relationship between the rules (selector precedence, etc.), and then
hopefully the different kinds of rules and metadata can flow into that.

OTOH, another question at the back of my mind is whether such a solution
should be flexible enough to express all kinds of metadata in different
conditions, or if it should be a solution just for the kinds of cases that
I've enumerated in the paper; after all, it doesn't have to be a part of
RDF, but can layer on top of it (I think), and it's pretty complex as it is;
trying to cover every conceivable case could make it unwieldy.

I suppose that this will become evident as more feedback comes in, and as
people try and fit what I'm trying to do with their use cases and
conceptions of RDF. One of the things I'd like to figure out soon is what
the next step is to get the right people talking about this.

Cheers,

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)

Received on Saturday, 30 September 2000 15:54:12 UTC