Re: RDFa Profiles, terms, and predicates (oh my!)

On Jul 22, 2010, at 23:02 , Shane McCarron wrote:

> I was working on my (implied) action item to update our vocabulary document so that it is an RDFa Profile, and I ran into something odd.  The rules for an RDFa Profile are pretty simple [1].  Shoehorning the required predicates into our existing pattern in the vocab document is a little daunting though.  I don't want to break what is already there (in case someone is depending upon it)... Here is that pattern:
> 
>   <dt id="alternate" about="#alternate" typeof="rdf:Property">alternate</dt>
>        <dd about="#alternate" property="rdfs:comment"
>          datatype="xsd:string"><span>alternate</span>  designates alternate
>          versions for a resource.</dd>
>      
> 
> Each term is defined that way.  All of our terms are defined within a containing bucket like this:
> 
>   <div id="relrev-properties" about="#relrev-properties" typeof="rdf:Bag">
> 
>   <div about="#relrev-properties" rev="rdfs:member">
>      
> Anyway.... our rules [1] require that in order for a term to be defined, it must be the common subject of two predicates; rdfa:term and rdfa:uri.  

_there must be_ a common subject for a term and a URI as a string. But I presume you just misspelled. 


> I completely understand why this is an attractive general case model.  I can map ANY term to ANY URI.  However, in reality, I expect that most vocabularies will be like ours - self-contained.  In other words the vocabulary document will define the term, and the URI for the term will be within that same document.  In the case above, for example, the URI for the term 'alternate' is http://www.w3.org/1999/xhtml/vocab#alternate.
> 
> With all this in mind, and in the spirit of never duplicating data needlessly in an RDFa document, I propose that we modify the RDFa Profile rules slightly.  That we say a term is defined by an 'rdfa:term' predicate.  That the term itself is the object of that predicate, and the URI is the object of an 'rdfa:uri' predicate on the same subject if one is provided.  Otherwise, the URI is the same as the subject of that predicate.

I am sorry, I am not sure I understand what you mean but let me try to reconstruct it. Do you propose that there are two ways of defining a term: either

<#alternate> rdfa:term "alternate" .

or

<SOMEURIDIFFERNENTFROM#alternate> rdfa:term "alternate" ; rdfa:uri "http://..../#alternate" .

Where, of course, the <....> can also be a blank node, ie, one could have

[] rdfa:term "alternate" ; rdfa:uri "http://..../#alternate" .

(The second alternative being the one we have today.)

I must admit this makes it a bit messy to me because I do not like having two very different approaches to define the same thing. But I also see 'modeling' issues with the

<#alternate> rdfa:term "alternate" .

In terms of RDF, this means I make a general statement _on the resource whose identifier is <#alternate>_. And this is not really correct. We do not say anything about the resource itself; we say something about the combination of a URI _as a string_ with a particular literal. In other words, when we define a term, we say something about two strings, namely

"alternate"

and

"http://...../alternate"

but we do not say anything whatsoever about the resource identified on the Web by <#alternate> (nor should we).

(For those who follow the RDF discussions: if we had the possibility to have a literal as a subject, then we could of course shorten that.)

(Yeah, I know, this is a price we _do_ play for using RDF for this purpose, but let us not reopen this issue now...). 

Ivan


> 
> Questions?  Comments?
> 
> [1] http://www.w3.org/TR/rdfa-core/#s_profiles
> 
> -- 
> Shane P. McCarron                          Phone: +1 763 786-8160 x120
> Managing Director                            Fax: +1 763 786-8180
> ApTest Minnesota                            Inet: shane@aptest.com
> 
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf