W3C home > Mailing lists > Public > public-powderwg@w3.org > December 2008

Datatype support confirmed (was Re: Na´ve question: Datatypes for RDF Properties?)

From: Phil Archer <phil@philarcher.org>
Date: Wed, 10 Dec 2008 13:37:30 +0000
Message-ID: <493FC61A.7010604@philarcher.org>
To: "Hammond, Tony" <t.hammond@nature.com>
CC: public-powderwg@w3.org

Tony, everyone,

Following this comment I have done a bit more work on the processor I'm 
building and have now got it to support attributes on descriptors 
properly. Actually, there's nothing special about this - as we're 
working in RDF/XML all I've done is to make sure that attributes on 
child elements of <descriptorset> are carried through the system.

The example POWDER doc at [1] includes this descriptor

<ex:foo rdf:datatype="http://www.w3.org/2001/XMLSchema#int">57</ex:foo>

Use that in the processor [2] and you get the right result out [3] 
including this triple:

<http://example.com/> ex:foo "57"^^http://www.w3.org/2001/XMLSchema#int

Phil.


[1] http://keg.icra.org/powder_examples/example_2_1_datatype.xml
[2] http://keg.icra.org/cgi-bin/processor.cgi
[3] http://tinyurl.com/6zepqu


Hammond, Tony wrote:
> Hi Phil:
> 
> Thanks for your answers. I updated the table to take account of both
> comments. (Also added in the respective POWDER and ORE mailing lists and
> archivesi as a reference convenience.)
> 
> I understand that the limitation to authprity-based URIs ("//...") may be be
> predicated on pragmatics and appreciate you pointing out the POWDER-BASE
> workaround for generic regex'es. (It is a shame though that some URIs are
> treated as more equal than others but then that's just a pet gripe of mine.
> ;)
> 
> Cheers,
> 
> Tony
> 
> 
> 
> On 9/12/08 12:49, "Phil Archer" <phil@philarcher.org> wrote:
> 
>> 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 Wednesday, 10 December 2008 13:38:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:42:13 GMT