Re: Small @profile question

On 9/9/2010 7:55 PM, Gregg Kellogg wrote:
>
> There's certainly a lot of precedent for using an external resource to 
> define things required to properly interpret HTML, or other content.
>
>     * We don't define all JavaScript need to present a document, we
>       include it using a <script> tag.
>     * We don't typically define all style information, it's included
>       using a <link rel="stylesheet"> tag.
>     * Many documents are not complete in and of them selves, but
>       reference each other using <link rel="next"> or similar.
>
>
> Looking at RDFa documents as a publication platform, I definitely see 
> a need to allow common definitions to be defined a separate file, for 
> much the same reason that I wouldn't want to repeat JavaScript and CSS 
> elements in the body of each HTML file. That's not to say that some 
> people won't want to define term and prefix mappings within the body 
> of a document, but for consistency among a set of similar documents, 
> the principle of "Don't Repeat Yourself" seems pretty important.

This was exactly the motivation for introducing this feature.  Well, 
this and the need for host languages (like XHTML+RDFa) to have a 
consistent way to define their operational environment in a way that is 
readily discoverable by an RDFa Processor.  In the case of host 
languages, it is really for the default vocabulary (if any) and the 
default collection of terms (if any), not for default prefix mappings.

Remember that the hallmark of RDFa is extensibility.  It HAS to be easy 
to define new ontologies, connect those to other ontologies, and use the 
terms defined in those ontologies in ways that are intuitive for our 
constituents.   Then, once those have been correctly used, be able to 
have knowledge engines follow their nose to get to the root of each term 
and infer meaning from them.

Finally, let me mention that everyone here *should* already be aware 
of.  The semantic web is ALL ABOUT retrieving other resources.  Subjects 
are URIs.  Objects can be URIs.  Predicates are URIs.  All of these 
might need to be retrieved.  If the whole Internet went down, none of 
that would work.  Introducing a mechanism that depends on retrieving 
some other URI doesn't increase this risk in my opinion.

I agree that there is opportunity for confusion every time you introduce 
a new feature.  If you want to use something that is defined in a 
profile, you need to reference that profile.  If that profile cannot be 
retrieved, NONE of the triples that depend upon that profile will be 
generated.  Moreover, an RDFa Processor has the ability to warn you that 
you didn't retrieve the profile.

This is surely better than the situation in RDFa 1.0 where we require 
that everyone define prefix mappings via @xmlns and define no mechanism 
at all for warning them if a prefix definition is missing.  It is surely 
less error prone than declaring all the prefix mappings each time I need 
them, with the possibility for a typo every time I do so.  At least if 
we have common profiles (like the one for XHTML+RDFa, or one that is 
defined by the Open Graph Protocol people) there is only one reference 
needed.  The processor can warn you if the URI of the profile is not 
resolvable.  If it resolves, the document author can be pretty confident 
they are getting the profile they want AND THEREFORE the declarations 
they expect.

Do I think that the great unwashed out there are going to be producing 
tons of RDFa Profiles?  Absolutely not.  I think there will be a few 
main profiles that lots of consumers will use (e.g., Google, Open Graph 
Protocol, the DAISY Consortium, Dublin Core).  I think that some 
organizations will define their own profiles so that they can simplify 
their own semantic markup (e.g., CNN might define their own profile, 
then reference it in all their pages so that they KNOW all the prefixes 
and terms they need are readily available).  I think this is no 
different than how common script libraries or stylesheets are used in 
the community.  And just as those seem to work most of the time, so will 
this.

(I am going to post more about this on my blog at blog.halindrome.com soon).

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com