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

[Dr. Ernie Prabhakar]

Hi Breton,

On Apr 12, 2006, at 6:50 PM, Breton Slivka wrote:

Ack, has it really been a month?  Sorry, things got busy...

>> = The Problem =
> 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.
Great idea!  Added:

http://microformats.org/wiki/rest/property#The_Problem

> 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.

Interesting.  I think the challenge with RDF historically is *not* so  
much its _lack_ of sufficiently powerful functionality, but more the  
"embarrassment of riches."  The goal of relProperty is to do  
something that is:
a) brain-dead simple
b) trivially insert-able in vanilla, validate-able HTML
c) easily accessed/updated via standard HTTP methods

I made a note about that on the wiki:

http://microformats.org/wiki/rest/property#relProperty

>> 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?

The former, I think; otherwise, it becomes difficult to "identify  
each individually update-able resource with its own URI."  Clarified  
at: http://microformats.org/wiki/rest/property#

>> = 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.

Well, I would recommend flat, at least to start with.  However, I'm  
not clear why ";" creates hierarchy problems?  My gut-level  
interpretation would be:

	;prop1;prop2 are chained properties
	;prop1/subprop1 is a "hierarchical" property

That is, we just reuse the existing HTML hierarchy separator.  What  
would be the problem with that?

> 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.

Captured here:
http://microformats.org/wiki/rest/property#Open_Issues

>
> 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.

Well, I worry that we're really treading into the space of HTML  
anchors.   I would think a more appropriate/general service might be  
something called "server side fragments", where a client somehow  
tells the server it wants it to *extract* that fragment, instead of  
(merely) jumping to it client side.

We could, I suppose, hypothesize appropriate syntaxes for it. I'd  
vote for "?#", as in "query fragment":

Client-side: http://www.example.org/contactpage#hcard
Server-side: http://www.example.org/contactpage?#hard

But, that would be innovating in a vacuum.  Best to let someone  
(you?) try to implement it first and see how it actually works, then  
document it here later. :-)

Thanks for all the feedback!

-- Ernie P.

>
>
>
> _______________________________________________
> microformats-rest mailing list
> microformats-rest at microformats.org
> http://microformats.org/mailman/listinfo/microformats-rest