relProperty Re: [uf-rest] Roy Fielding on WebDAV and PROPs

[Breton Slivka]

Thank you Ernie, this is indeed making a lot more sense to me now.  
Maybe someday I may be able to contribute intelligently to this  
discourse.  I have a couple of responses to your wiki entry.


> = The Problem =
>
> HTML has long used the [http://www.w3.org/TR/REC-html40/struct/ 
> global.html#h-7.4.4 meta] tag for metadata to describe the  
> ''contents'' of a document.  While this works well for "intrinsic"  
> metadata related to authoring, there's no equivalent function for  
> "extrinsic" metadata provided by the server or external sources.
>

perhaps a couple of examples of what would amount to extrinsic  
metadata wouldn't be too far afield, and serve to sharpen the focus  
of the problem a bit more.


> = Proposal =
> == relProperty ==
>
> Our proposal, currentlly called "relProperty", is motivated by the  
> following principles:
>
> # Every property must have at least one well-defined URL which can  
> be retrieved and updated.
> # There must be an easy way to discover all the properties  
> associated with a given document.
> # It must be simple to implement on existing web servers without  
> requiring non-trivial modifications
> # It should respect and build on existing [http://microformats.org/ 
> about/ microformat principles] and practices
> # It should be consistent with URL [[rest/opacity]] (properly  
> understood)
>

I am in the process of trying to determine how much of this is  
already accounted for, and dealt with in the RDF specification. I  
can't say I fully understand RDF, but a lot of this is sounding  
familiar from when I tried to understand it . From what I understand,  
there are already mechanisms to link to RDF descriptions from inside  
an HTML page. I think there might be URL schemes for RDF properties  
already worked out as well. I'm not sure though.  Since we're talking  
about metadata, there needs to be some form of metadata format we're  
dealing with. Perhaps it's RDF, or some theoretical mf style  
equivalent (such as xmdp).

The part that I haven't seen is an *implementation* where properties  
become readable/writable from within a simple URI schema.


> == <link> ==
>
> Together, this implies that that the optimal way to associate a  
> property with a document is via the HTML [ link] tag (or the  
> equivalent HTTP "Link:").  This provides the requisite mechanism  
> for telling the client how to construct an appropriate URL for  
> getting or setting each property, as in:
>
>  <link rel="property" href=".;prop1">
>
> == ;property ==
>
> It is conventional, but not mandatory, to use a semicolon (";") as  
> the first character of each property.  This follows the convention  
> used in, e.g. [http://www.macromedia.com/cfusion/knowledgebase/ 
> index.cfm?id=1c6b723 ColdFusion], and eases human-readability.
>

Are you talking about listing each property seperately in their own  
link statement? Or a link to a file describing the URI schema in use  
for the properties of that page?

>
> = Open Issues =
>
> * Can properties be chained together? If so, are they retrieved in  
> parallel, or would those be subproperties?
> * Would we need to worry about [http://lists.evolt.org/archive/Week- 
> of-Mon-20020114/065707.html semicolon exploits]?
> * Are there other conventions we should follow/avoid?
> * Should the "Link:" tag itself be declared in HTTP "OPTIONS"?

issue  1:   It depends on whether our metadata is going to be flat or  
heirarchical I suppose. if it's the latter, semicolon may not be the  
best choice for use in a URL schema, as it presents a number of  
technical problems.

Issue 2: Problems like this can be avoided through simple precautions  
and good programming practice. if necessary, guidelines for URL  
parsing could be drafted. The thing to avoid is using unfiltered URL  
text directly as an SQL query. It is untrustworthy data. Numerous  
functions exist to deal with this sort of thing already. Security  
problems happen when coders don't know this, or are too lazy to use  
them.

Issue 3:  As mentioned above, it would probably be a good idea to see  
how much overlap there is in RDF in dealing in this problem space.

Random Brainstorm:  Since we're talking about giving URI's to  
extrinsic metadata, is it crazy to think it would be useful to create  
URI's for intrinsic /data/? That is to say, a server provided way to  
deal directly with microformats. A little off topic yes, but here's  
what I'm thinking:

Say for example this URI contains several hcards http:// 
www.example.org/contactpage

It's possible to then provide a server switch to automatically turn  
this page into rest service:

GET http://www.example.org/contactpage/hcard/01;fn        //retrieve  
fn prop from first hcard
GET http://www.example.org/contactpage/hcard/02/adr;locality  // 
retrieve a subproperty from second hcard.
POST http://www.example.org/contactpage/hcard/new              //post  
url encoded properties to build a new hcard and place on contactpage.

just as an example.  but I think it's an idea with some potential,  
even if it's a far off pipe dream.