Re: Naïve question: Datatypes for RDF Properties?

Hi Tony,

Not a naive question at all. I noticed that you'd raised this on your 
blog and added a note to my To Do list to take a look at this. I was 
really pleased to see your ORE/POWDER/sitemap comparison [0] - very 
interesting. I'd been meaning to do something similar and now, joy of 
joys, I don't have to!

The short answer to your question about data types is yes, POWDER 
supports typed literals - there's no reason not to. The reason we warn 
strongly against anything with blank nodes is that a DR can (indeed 
generally will) apply to resources that don't exist at the time the DR 
was created. This has problems for semantics, see [1]. But that doesn't, 
AFAIK, mean we can't handle datatypes.

I just created a little example POWDER file with a datatype [2] which 
I'm pleased to say validates. But if I put it through my processor [3] 
the datatype stuff is missed off. This shows that I need to fix a bug in 
the processor, not that RDF datatypes aren't supported.

If I may, I'd like to answer your other comment [4] while I'm here.

On the first point, you're right of course. The final version of the 
grouping Doc will not include the colon in the scheme in the cited diagram.

On the more substantive point about including \/\/ in the template 
regular expressions and therefore making POWDER apply only to IRIs of 
the form scheme://... we discussed this on our call yesterday.

'POWDER' has 3 different flavours: POWDER, POWDER-BASE and POWDER-S.

POWDER is about resources on the Web with IRI constraints defined to 
make group definitions as easy as possible (includehosts, 
excludepathendswith etc.). However, in order to make sure that other URI 
schemes can be used, we introduce an intermediate step between POWDER 
and POWDER-S, known as POWDER-BASE. This only has two elements in an IRI 
set definition: includeregex and excluderegex (in all other aspects it's 
the same as POWDER).

POWDER-BASE is the key to the IRI set definition extension mechanism - 
any URI can be matched against any regular expression (using the XQuery 
syntax we refer to) and there is certainly no requirement that these 
include ://. The extension examples in the grouping doc [5] include an 
ISAN number for instance. In efect, POWDER is an extension of 
POWDER-BASE: one that's designed to handle HTTP and HTTP-like URIs. 
POWDER-BASE and POWDER-S are much less restrictive.

Thanks again for your comments - I hope they've answered satisfactorily?

Phil.

[0] http://tinyurl.com/5bcsuy
[1] http://lists.w3.org/Archives/Public/public-xg-wcl/2006Jun/0000.html
[2] http://keg.icra.org/powder_examples/example_2_1_datatype.xml
[3] http://tinyurl.com/6zepqu
[4] http://lists.w3.org/Archives/Public/public-powderwg/2008Dec/0031.html
[5] http://www.w3.org/TR/2008/WD-powder-grouping-20081114/#extension

Hammond, Tony wrote:
> Hi:
> 
> I have a naïve question about property values for descriptor sets. From the
> FORMAL SEMANRICS draft:
> 
>     "3.2 Descriptor Set Semantics
>     3.2.1 Descriptor Sets expressed as RDF Properties and Values
> 
>     A descriptor set contains RDF properties that have fillers that are not
> blank nodes and that do not identify either a class or a property, ..."
> 
> This would seem to imply that the RDF properties are simple literals or
> resources and compound values are not allowed. Is that right? And is there
> any possibility for datatyping literals?
> 
> Cheers,
> 
> Tony
> 
> 
> ********************************************************************************   
> DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
> not the original intended recipient. If you have received this e-mail in error
> please inform the sender and delete it from your mailbox or any other storage
> mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
> liability for any statements made which are clearly the sender's own and not
> expressly made on behalf of Macmillan Publishers Limited or one of its agents.
> Please note that neither Macmillan Publishers Limited nor any of its agents
> accept any responsibility for viruses that may be contained in this e-mail or
> its attachments and it is your responsibility to scan the e-mail and 
> attachments (if any). No contracts may be concluded on behalf of Macmillan 
> Publishers Limited or its agents by means of e-mail communication. Macmillan 
> Publishers Limited Registered in England and Wales with registered number 785998 
> Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
> ********************************************************************************
> 
> 
> 

-- 
Phil Archer
w. http://philarcher.org/

Received on Tuesday, 9 December 2008 12:49:52 UTC