Re: vCard/iCalendar RDF process document 2007-04-06

Kjetil,

Maybe there's some confusion here between A ) the comprehensiveness of 
an ontology, and B ) ontology support by any particular RDF processor. 
Your problem seems to be on point B: you don't want to force your 
particular processor to have to understand the entire RDF vCard 
ontology. Fine. I don't care if your processor understands only 50% of 
the RDF vCard ontology. In fact, I don't care if your processor 
understands only 1% of the RDF vCard ontology. This is RDF---you parse 
in all nodes of an RDF graph, whether you understand all of it or not. 
In fact, with RDF you can round-trip without understanding a bit of it.

But that doesn't mean the ontology can't be complete, and cover all the 
information that non-RDF vCard would support. I'm strongly against 
different subsets of the ontology. In my opinion this would make 
understanding the spec harder and impede adoption because of the 
proliferation of variations.

The only point left to consider here is the "value-switching" in my 
current document, allowing vcard:firstName, for instance, to be a 
literal, an rdf:value bnode, or an rdf:List of rdf:value bnodes. This 
does not cause a significant processing problem, and certainly does not 
necessitate different ontology subsets. Only a simple routine is needed, 
shown here in pseudocode (with type casting removed for simplicity):

Literal[] getLiterals(Resource resource, Property property)
{
  Value value=resource.getProperty(property);
  if(value is Literal)
  {
    return new Literal[]{value};
  }
  else if(value is Resource)
  {
    return new Literal[]{value.getProperty(rdf:value)};
  }
  else if (value is List)
  {
    Literal[] literals=new Literal[value.length];
    for(i=0; i<value.length; i++)
    {
      literals[i]=value[i].getProperty(rdf:value);
    }
    return literals;
  }
}

There. That's value flipping. That's all the complexity that will be 
added to a processor to support value flipping. You can call 
getLiterals(resource, vcard:firstName), for instance, and the value that 
will be returned will be no different than if we had required 
vcard:firstName to be an rdf:List in every single instance.

Conclusion: I see no need for and I am strongly against ontology subsets.

Garret

Kjetil Kjernsmo wrote:
> On Saturday 28 April 2007, Garret Wilson wrote:
>   
>> It's too bad I missed that debate; there certainly doesn't seem to be
>> strong feelings one way or another on this list at the moment. :) My
>> feelings are pretty strong for full representation; it would be
>> pitiful, in my view, if the RDF ontology data was restricted to the
>> range of hCard.
>>     
>
> OK, I can absolutely see the case for that. However, I think that for a 
> lot of applications, full vCard is overkill, I've had some looks at the 
> Perl module Text::vCard's parse tree, and it is pretty nasty. 
>
> For implementers, I think it is a good thing to have a restricted set to 
> relate to, so how about we define a RDF vCard Core, which is the hCard 
> subset, and RDF vCard Full, which is the full vCard?
>
> Cheers,
>
> Kjetil
>
>

Received on Tuesday, 1 May 2007 16:10:46 UTC