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

Hi Stasinos:

Many thanks for your comments. Certainly something to ponder on. (I do see
where you're coming from. And it's useful to have the POWDER-BASE
sanctuary.)

I just wanted to pick on one comment you made. You say "specifically
targeted at the web" and "to be used in web applications". But there is only
one Web. Only one global information space. As AWWW [1] defines it:

    "The World Wide Web (WWW, or simply Web) is an information space in
which the items of interest, referred to as resources, are identified by
global identifiers called Uniform Resource Identifiers (URI)."

And it makes clear later [2] that identification, interaction and
representation are *orthogonal* concepts.

>From a URI pattern matching perspective what matters as regards URL type
things ("information resources") is not whether representations are
available but whether the URI has an authority component that can be matched
on.

> feature, and a good one IMO, not a bug. Would you *really* want
> that <includehosts> restrictions can match a <urn:ISAN-number> IRI?

Actually if generic URI patterns were supported I would rather hope that any
<includehosts> restriction would fail to match any URNs. :)

Cheers,

Tony

[1] http://www.w3.org/TR/webarch/
[2] http://www.w3.org/TR/webarch/#orthogonal-specs


On 9/12/08 16:15, "Stasinos Konstantopoulos" <konstant@iit.demokritos.gr>
wrote:

> Tony, hi.
> 
> On Tue Dec  9 15:27:24 2008 Hammond, Tony said:
> 
>> 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.
>> ;)
> 
> If I may same so, it would, indeed, be a shame if some URIs were treated
> as more equal than others, but they are not. In fact, this WG has spent
> a significant proportion of its total effort in making sure that there
> is nothing specific to resolvable URLs lurking in POWDER's foundations.
> 
> The formal essence of the grouping-by-name mechanism is the BASE and
> OWL/RDF formalisms. Application builders are free to define any
> <in/exclude*> grouping restrictions they like, as long as they can be
> translated into <in/excluderegegexp>. There is nothing special
> whatsoever about <includehosts>, except that the WG bothered to define
> it (again, NOT in POWDER-BASE but in POWDER/XML which is specifically
> targeted at the web). Note how POWDER/XML is defined using POWDER-BASE
> primitives making no special concession to better or more easilty
> accommodate resolvable things. This has, by the way, cost us port ranges
> since numeric comparisons are really hard to "emulate" with regexps, but
> we didn't want to add any URL-specific portrange elements in -BASE.
> Note also how in the grouping doc we use POWDER-BASE primitives to
> define grouping elements for (non-resolvable) ISAN-number URIs.
> 
> This is, IMHO, one of the strongest aspects of POWDER: we expect that it
> is mostly going to be used in web applications, but there is no
> "increased equalness" whatsoever towards resolvable URIs.
> 
> Going back to the beginning of the thread, we anchor <includehosts>
> restrictions on :// and keep other IRIs from matching. This is a
> feature, and a good one IMO, not a bug. Would you *really* want
> that <includehosts> restrictions can match a <urn:ISAN-number> IRI?
> Do you have a use case in mind where one would need that?
> 
> Best,
> s


********************************************************************************   
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 Wednesday, 10 December 2008 16:38:49 UTC