Re: rdf:XMLLiteral and the RDF namespace

(I add the RDFa WG to the cc list, because that discussion should be properly followed and archived as part of the WG list)


On Apr 29, 2010, at 06:16 , Mark Birbeck wrote:

> Hi Ivan,
> 
>>> But now that RDFa 1.1 has a more cohesive story about about CURIEs and
>>> tokens being applied consistently across all of our attributes, we
>>> should consider creating an 'xmlliteral' token to sit alongside
>>> 'next', 'prev', 'license', etc.
>>> 
>> 
>> But this is not only an rdf:XMLLiteral issue, is it?
> 
> That's true, but rdf:XMLLiteral is the only data type that is referred
> to in the processing rules. It does therefore have a special position
> in RDFa.

Formally yes. But we do refer to xsd explicitly all over the place, too... 

> 
> 
>> If the XHTML code contains an explicit
>> @datatype="xsd:integer", this also requires the definition of the xsd prefix. Do you mean
>> that we should define a term for all the XSD datatypes?
> 
> No, I wasn't suggesting that...but now you say it, I don't think it's
> such a bad idea. :)

:-) 

> At the very least, we should consider defining
> some basic types, such as integers and dates.
> 

Yes, we could think of doing that, indeed. See also below

> 
>> There is quite a load of them, and
>> there is a danger that those terms would clash with terms used elsewhere (remember that
>> we do not have any association that says that a specific term can be used with a specific
>> attribute only...)
> 
> That's true, although I'm not sure what the scenarios would be where
> we clash with tokens that people have defined, such as 'integer',
> 'date', etc.

Maybe true. I should go through all the xsd datatypes to see if there is any danger and I am at WWW right now, with not that much time for checking something like that:-)

(I still have the eery feeling that we may need that extra possibility to restrict a specific term to specific attributes...)

> 
> 
>> We had some discussion about defining default prefixes. One possibility would be to say
>> that prefixes for all standard W3C URIs vocabularies are automatically defined by default,
>> ie, rdf, rdfs, skos, owl, xsd, powder (I may forget some). The inclusion of non-standard
>> prefixes like foaf, dc, or cc, might be more touchy in terms of (social) process, but I do not
>> see any issue with standard w3c vocabularies...
> 
> That's also a way to go, but forgive me for saying that I don't think
> it aims high enough.
> 
> I think we want Microformats-like simplicity in the resulting markup,
> and that means we need to exposed complex features in a simple way.
> With tokens and @vocab, authors can go a long way without having to
> make use of prefix mappings, so I'd like to see us continue in that
> direction.
> 

So a default profile (if we go down that line, that is) could

- include prefixes for standard vocabularies
- include terms for some of the most important datatypes, including XMLLiteral
- maybe, but only maybe, terms for some of the most important rdf/rdfs/owl terms like seeAlso or sameAs

although, I must admit, I am quite weary about the third thing because, well, how would we pick those terms? We do not really have a statistics to rely on... But that important point is that a profile file can include all these in one place

Cheers

Ivan






> Regards,
> 
> Mark
> 
> --
> Mark Birbeck, webBackplane
> 
> mark.birbeck@webBackplane.com
> 
> http://webBackplane.com/mark-birbeck
> 
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)


----
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