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

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

Received on Tuesday, 9 December 2008 15:28:16 UTC