Re: Small @profile question

Nathan wrote:
> 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.

Apologies, I realised that I completely forgot one paragraph in this 
reply, as follows:

Succinctly, it is possible to create a valid RDFa document which 
contains a valid RDF Graph, which, without changing the RDFa Document or 
RDFa Specification can vary temporally to:
- become invalid,
- contain no RDF Graph or only part of the expected serialized RDF Graph,
- contain a different RDF Graph to that contained in different 
serializations served via content negotiation.

Regardless, I trust that the Working Group has weighed up all of the 
pros and cons, thus making the inclusion of @profiles in RDFa an 
informed decision made with wide open eyes. As mentioned in my original 
mail, this was more for my own peace of mind ensuring that the raised 
points had been fully considered / are not new :)

Best,

Nathan

> 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 08:03:57 UTC