Re: Small @profile question

Shane McCarron wrote:
> 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.

Honestly, I understand where you are coming from, and as a developer 
generally see great benefits in this approach, using it myself for the 
likes of javascript and css.

However, the issue I have is that all of the examples given and afaict 
every other use of this pattern doesn't fundamentally break the Document 
itself.

Even if every linked stylesheet, javascript and embedded link in an HTML 
Document fails, you still have an HTML Document which can be parsed, 
analysed, processed, transformed, validated and presented to a human. 
You still have a Document, you can still create and instantiate the DOM.

Whereas if the profile is missing from and RDFa document which depends 
on it, then you cannot create or instantiate (either all or part of) the 
RDF Graph, you cannot parse, analyse, process, transform or even 
validate the document.

One could argue that you can still parse and validate, however the parse 
would not be successful, and the only kind of validation that could 
return success was basic syntax, if it was an RDF validator that 
supported RDFa 1.1 then it would fail too.

I'm aware that the semantic web is all about retrieving other resources, 
but said retrieving of other resources is to further augment your graph, 
to consider additional information, to reason and infer and so forth. 
The retrieval of the other resources is not required to be able to parse 
the resource you are currently considering.

One thing I am 100% sure of, is that time will tell on this one, and 
this is a scenario where I sincerely hope I'm wrong :)

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

Will look forward to the post,

Best,

Nathan

Received on Friday, 10 September 2010 02:14:14 UTC