W3C home > Mailing lists > Public > public-grddl-comments@w3.org > July to September 2008


From: Harry Halpin <hhalpin@ibiblio.org>
Date: Mon, 25 Aug 2008 13:46:21 +0100
Message-ID: <48B2A99D.10503@ibiblio.org>
To: Ian Hickson <ian@hixie.ch>
Cc: Julian Reschke <julian.reschke@gmx.de>, Danny Ayers <danny.ayers@gmail.com>, Dan Connolly <connolly@w3.org>, "Booth, David (HP Software - Boston)" <dbooth@hp.com>, "public-grddl-comments@w3.org" <public-grddl-comments@w3.org>

Ian Hickson wrote:
> On Mon, 25 Aug 2008, Harry Halpin wrote:
Just to double-check:

You don't have any problems with GRDDL's use of profile if it's a 
@rel="profile", or GRDDL's use of @rel="transformation", correct?
>> But you might want to make your own profile, say "microChemistry", and 
>> give it a profile page, and use that profile. Profiles are extensible.
> You could do the same thing but without the profile page, just by adding 
> the transformation to your list of GRDDL transformations. Then it would 
> even work on pages that use your vocabulary but forgot to copy the 
> profile="".
Yes, that would be true, but you'd have to explicitly add it to your 
list of GRDDL transformations. Which is also work. So, for agents when 
encountering a profile that has a transformation that is not locally 
cached, they could "dynamically" run the GRDDL tranformation by going to 
the profile page.
>> The general idea behind using profiles was *not* as a substitute for a a 
>> link to a GRDDL transform, but that authors that use profiles could add 
>> a link to GRDDL transform to their profile page, and the GRDDL algorithm 
>> could look for a GRDDL transform there if one wasn't directly linked. 
>> Think of it as a short-cut for document authors - they just have to 
>> think about using particular profiles, rather than directly linking to a 
>> GRDDL transformation.
> Not having a profile="" attribute is also a shortcut for document authors. 
> Instead of having to think about using particular profiles, they just have 
> to use them, possibly without knowing (e.g. by pasting in code from tools 
> or other pages).

Yes, that is what microformats in the wild does. There are concerns 
about naming clashes, etc. which I am not sure how the microformat 
community plans to resolve. URIs are one way, so are profiles, etc. All 
have issues, depending on your preference.

>> That way the owner of the profile document can upgrade the GRDDL 
>> transformation once without modifying all instance data that uses that 
>> profile.
> I understand that the RDF community believes that it is better for content 
> to define how its vocabularies work (whatever that means) rather than 
> having the tools just natively support the vocabularies, but it seems much 
> better to me to just have the tools natively support the vocabularies. 
> That way, you upgrade the tool and everything works better, instead of 
> having to upgrade the tool and the vocabulary definitions and hope that 
> everyone has linked everything together.
Well, I am in support of both, just as different options, so one can get 
the best of both worlds - tools that upgrade their vocabularies 
dynamically in a decentralized environment, but also tools that allow 
the most common vocabularies to be part of the default - as long as the 
user maintains control of their tool. But I in no-way speak for the rest 
of the GRDDL community, much less the RDF community as a whole.
>> So, our "microChemistry" profile page could embed a GRDDL tranformation 
>> directly in that profile page, or require all instance data to both list 
>> the profile page and a rel="transformation" directly to the profile. The 
>> first seems easier.
> Wouldn't the easiest option just be for people who want to use GRDDL to 
> obtain "microChemistry" data to just tell GRDDL about microChemistry, and 
> not require the authos to do any linking at all?
>> Again, the use of profiles and direct linking to a GRDDL transform via 
>> rel="transformation" are two separate cases. I assume you are happy with 
>> rel="transformation" rather than rel="grddl-transformation".
> I am, but some people seem to think that clashes are a problem and would 
> rather that all names be long URLs, so others may object.
Received on Monday, 25 August 2008 12:46:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:03 UTC