subject:"isDefinedBy and isDescribedBy, Tale of two missing predicates"

The original of this was sent from my Talis e-mail address which is 
being held up so I'll circumvent the system and use my w3.org address to 
get into the debate without further delay ;-)


On 05/11/2010 09:12, Phil Archer wrote:

Dave,

I just went back to check thinking oh no, we didn't restrict the range
of describeby did we? 'Cos adding ranges to predicates is almost always
a dumb thing to do unless you really, really need to, 'cos someone might
want to use it to mean what you thought you meant all along.

Hmmm... looking at the actual POWDER vocabulary namespace document at
http://www.w3.org/2007/05/powder-s#describedby it, er seems that, erm,
well, we did.

Bother.

Stupid, stupid stupid. :-(

Hmmm... tempted to think about how this might be corrected.

Phil.

On 05/11/2010 08:51, Dave Reynolds wrote:

On Thu, 2010-11-04 at 20:58 -0400, Kingsley Idehen wrote:


When you create hypermedia based structured data for deployment on an
HTTP network (intranet, extranet, World Wide Web) do include a
relation that associates each Subject/Entity (or Data Item) with its
container/host document. A suitable predicate for this is:
wdrs:describedBy [2] .


Ian mentioned this predicate in his post.

Looking at [1] the range of wdrs:describeBy is given as class of POWDER
documents and is a sub class of owl:Ontology which seems to make it
unsuitable as a general predicate for the purpose being discussed here.

Dave

[1] http://www.w3.org/TR/powder-dr/#semlink




Please consider the environment before printing this email.

Find out more about Talis at http://www.talis.com/
shared innovation™

Any views or personal opinions expressed within this email may not be
those of Talis Information Ltd or its employees. The content of this
email message and any files that may be attached are confidential, and
for the usage of the intended recipient only. If you are not the
intended recipient, then please return this message to the sender and
delete it. Any use of this e-mail by an unauthorised recipient is
prohibited.

Talis Information Ltd is a member of the Talis Group of companies and
is registered in England No 3638278 with its registered office at
Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.





--


Phil Archer
W3C Mobile Web Initiative
http://www.w3.org/Mobile

http://philarcher.org
+44 (0)1473 434770
@philarcher1

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates


On 11/5/10 4:51 AM, Dave Reynolds wrote:

On Thu, 2010-11-04 at 20:58 -0400, Kingsley Idehen wrote:


When you create hypermedia based structured data for deployment on an
HTTP network (intranet, extranet, World Wide Web) do include a
relation that associates each Subject/Entity (or Data Item) with its
container/host document. A suitable predicate for this is:
wdrs:describedBy [2] .

Ian mentioned this predicate in his post.

Looking at [1] the range of wdrs:describeBy is given as class of POWDER
documents and is a sub class of owl:Ontology which seems to make it
unsuitable as a general predicate for the purpose being discussed here.

Dave

[1] http://www.w3.org/TR/powder-dr/#semlink





Dave,

I am not saying or implying that Ian didn't say this in his post. These 
issues have been raised many times in the past by others (including 
myself), repeatedly. Here's the key difference though, yesterday was the 
first time that these suggestions were presented as somehow being 
mutually exclusive relative to use of 303 redirection.


I don't want to start another session with Ian, but here is my 
fundamental issue:
Fixing RDF resources doesn't have to be at the expense of 303 
redirection (mechanism for resolve. At the end of the day there are 
going to be resolvable object/entity identifiers either side of these 
predicates, if we are seeking to keep the resulting Linked Data mesh 
intact etc..


dropping 303 simply didn't need to be the focal point of the 
conversation. It has nothing to do with why people have been publishing 
old school RDF resources that fail to link the container (rdf doc) 
with its structured content (triples).


I hope I've made my point clear :-)

--

Regards,

Kingsley Idehen 
President  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

2010-11-05 Thread Dave Reynolds

On Fri, 2010-11-05 at 07:19 -0400, Kingsley Idehen wrote:
 On 11/5/10 4:51 AM, Dave Reynolds wrote: 
  On Thu, 2010-11-04 at 20:58 -0400, Kingsley Idehen wrote:
  
   When you create hypermedia based structured data for deployment on an
   HTTP network (intranet, extranet, World Wide Web) do include a
   relation that associates each Subject/Entity (or Data Item) with its
   container/host document. A suitable predicate for this is:
   wdrs:describedBy [2] .
  Ian mentioned this predicate in his post.
  
  Looking at [1] the range of wdrs:describeBy is given as class of POWDER
  documents and is a sub class of owl:Ontology which seems to make it
  unsuitable as a general predicate for the purpose being discussed here.
  
  Dave
  
  [1] http://www.w3.org/TR/powder-dr/#semlink
  
  
  
  
 Dave,
 
 I am not saying or implying that Ian didn't say this in his post.
 These issues have been raised many times in the past by others
 (including myself), repeatedly. 

Indeed. 

I was only responding on the specific suggestion to use wdrs, not
intending any broader comment.

 Here's the key difference though, yesterday was the first time that
 these suggestions were presented as somehow being mutually exclusive
 relative to use of 303 redirection.
 
 I don't want to start another session with Ian, but here is my
 fundamental issue: 
 Fixing RDF resources doesn't have to be at the expense of 303
 redirection (mechanism for resolve. At the end of the day there are
 going to be resolvable object/entity identifiers either side of these
 predicates, if we are seeking to keep the resulting Linked Data mesh
 intact etc..
 
 dropping 303 simply didn't need to be the focal point of the
 conversation. It has nothing to do with why people have been
 publishing old school RDF resources that fail to link the container
 (rdf doc) with its structured content (triples).
 
 I hope I've made my point clear :-)

Yes but I don't think the proposal was to ban use of 303 but to add an
alternative solution, a third way :)

I have some sympathy with this. The situation I've faced several times
of late is roughly this:

Reasonable and technically skilled person new to linked data reviews the
field with the intention of trying it out and concludes:

(a) Separating URIs for Things[0] and URIs for Documents containing
assertions (data, descriptions, attribute values, whatever) about those
things make sense [1].

(b) I want my Thing URIs to resolve but I don't want to use # URIs for
reasons foo/bar/baz [2].

(c) The Tag finding [3] means that we cannot use slash URIs for Things
unless we include a 303 redirect.

(d) Ergo we must use 303.

(e) Whoops this use of 303 is proving to be a barrier to adoption for my
users, maybe I'll switch to an easier technology [4].

Clearly simply using # URIs solves this but people can be surprisingly
reluctant to go that route.

I take this discussion to be exploring the question:

Would a third alternative be possible?  People can continue to
use # URIs and to use slash URIs with 303s but would it be that
bad if we allowed people to use slash URIs for Things, without
the redirect?

The talk of dropping and deprecating I've heard has been concerned
with the TAG finding on http-range-14 (which does ban use of slash URIs
for Things and thus is a genuine, standards-body-backed, objection to
such a third way) rather than to the use of 303s by those happy to do
so.

Hope this helps rather than muddies things further.

Cheers,
Dave

[0] I'm going to trying use the terminology of Thing and Document here
rather than NIR and IR - inspired by Tim's historical note (thanks to
Andy Seaborne for point this out):
http://lists.w3.org/Archives/Public/www-tag/2009Aug/.html

[1] Note that some people conclude something more like this is a
philosophical distinction that I don't care about, I'll go hang with a
different crowd. This not the branch we're concerned with here.

[2] See for example the reasons cited in Tim's historical summary note.

[3] http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039

[4] Note that I'm in no way suggesting that 303 redirects is the only or
the biggest barrier to adoption. It just has a way of triggering
conversations with users and early adopters that tend to be
counterproductive.

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates


Dave Reynolds wrote:

Clearly simply using # URIs solves this but people can be surprisingly
reluctant to go that route.


Why? I still don't understand the reluctance, any info on the technical 
non-made-up-pedantic reasons would be great.


Best,

Nathan

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

2010-11-05 Thread Leigh Dodds

Hi Dave

On 5 November 2010 12:35, Dave Reynolds dave.e.reyno...@gmail.com wrote:
 Yes but I don't think the proposal was to ban use of 303 but to add an
 alternative solution, a third way :)

 I have some sympathy with this. The situation I've faced several times
 of late is roughly this:

 ...
[snip]

Really nice summary Dave.

Cheers,

L.

-- 
Leigh Dodds
Programme Manager, Talis Platform
Talis
leigh.do...@talis.com
http://www.talis.com

wdrs Error (was Re: isDefinedBy and isDescribedBy, Tale of two missing predicates)

Adding Public POWDER list. Main thread is on 
http://lists.w3.org/Archives/Public/public-lod/2010Nov/


It's clear to me that there is an error in wdrs:describedby. And since I 
am one of the originators of it, I'd like to do something about it.


What I wrote, and meant, in the text at [1] was:
... [wdrs:describedby] is a generic relationship type that does not of 
itself imply that the link points to a POWDER document — that is done by 
the specific Media type. The formal definition of describedby is given 
in Appendix D.


Appendix D is where it says:

The relationship A 'describedby' B asserts that resource B provides a 
description of resource A. There are no constraints on the format or 
representation of either A or B, neither are there any further 
constraints on either resource.


However, later in the same document, at [2] it says

We define the RDF property wdrs:describedby with a domain of 
rdf:Resource and a range of wdrs:Document. This is the class of POWDER 
documents and is a sub class of owl:Ontology. The meaning of 
wdrs:describedby is identical to the describedby relationship type 
defined above so that:


http://www.w3.org/2007/05/powder-s#describedby

and

http://www.iana.org/assignments/relation/describedby

So we have a mis-match Either wdrs:describedby has a range of 
wdrs:Document (bad) or it has the same semantics as the @rel type 
describedby which implies no range at all (good).


I'd like to correct this error!! wdrs:describedby is intended to be used 
exactly as is being discussed here - a generic link between A and B such 
that B describes A with no constraints at all on either.


Since I can (readily) point to an error in the description of what I 
hope is a basically sound design, I'm going to see if I can:


a) add an erratum to the POWDER Rec
b) edit the wdrs namespace documentation

That should I hope, make wdrs:describedby fully usable??

(Looks up W3C process document on getting this done...)

Phil

[1] http://www.w3.org/TR/powder-dr/#assoc-linking
[2] http://www.w3.org/TR/powder-dr/#semlink

On 05/11/2010 12:35, Dave Reynolds wrote:

On Fri, 2010-11-05 at 07:19 -0400, Kingsley Idehen wrote:

On 11/5/10 4:51 AM, Dave Reynolds wrote:

On Thu, 2010-11-04 at 20:58 -0400, Kingsley Idehen wrote:


When you create hypermedia based structured data for deployment on an
HTTP network (intranet, extranet, World Wide Web) do include a
relation that associates each Subject/Entity (or Data Item) with its
container/host document. A suitable predicate for this is:
wdrs:describedBy [2] .

Ian mentioned this predicate in his post.

Looking at [1] the range of wdrs:describeBy is given as class of POWDER
documents and is a sub class of owl:Ontology which seems to make it
unsuitable as a general predicate for the purpose being discussed here.

Dave

[1] http://www.w3.org/TR/powder-dr/#semlink





Dave,

I am not saying or implying that Ian didn't say this in his post.
These issues have been raised many times in the past by others
(including myself), repeatedly.


Indeed.

I was only responding on the specific suggestion to use wdrs, not
intending any broader comment.


Here's the key difference though, yesterday was the first time that
these suggestions were presented as somehow being mutually exclusive
relative to use of 303 redirection.

I don't want to start another session with Ian, but here is my
fundamental issue:
Fixing RDF resources doesn't have to be at the expense of 303
redirection (mechanism for resolve. At the end of the day there are
going to be resolvable object/entity identifiers either side of these
predicates, if we are seeking to keep the resulting Linked Data mesh
intact etc..

dropping 303 simply didn't need to be the focal point of the
conversation. It has nothing to do with why people have been
publishing old school RDF resources that fail to link the container
(rdf doc) with its structured content (triples).

I hope I've made my point clear :-)


Yes but I don't think the proposal was to ban use of 303 but to add an
alternative solution, a third way :)

I have some sympathy with this. The situation I've faced several times
of late is roughly this:

Reasonable and technically skilled person new to linked data reviews the
field with the intention of trying it out and concludes:

(a) Separating URIs for Things[0] and URIs for Documents containing
assertions (data, descriptions, attribute values, whatever) about those
things make sense [1].

(b) I want my Thing URIs to resolve but I don't want to use # URIs for
reasons foo/bar/baz [2].

(c) The Tag finding [3] means that we cannot use slash URIs for Things
unless we include a 303 redirect.

(d) Ergo we must use 303.

(e) Whoops this use of 303 is proving to be a barrier to adoption for my
users, maybe I'll switch to an easier technology [4].

Clearly simply using # URIs solves this but people can be surprisingly
reluctant to go that route.

I take this discussion to be exploring the question:

 Would a third

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates


OK, I need to add my two penneth here.

I wrote a short blog entry-like piece last night [1]. My basic point 
being that I agree wholly with Ian's analysis but disagree with his 
conclusions and I argue the case for a new HTTP status code.


I've taken a keen interest in this kind of thing for a while as it 
chimes with the discussion that went on around identifying metadata for 
a given resource (which is relevant to the work I did on POWDER). 
Metadata discovery was discussed at length in the W3C TAG and is at the 
heart of the Web Linking RFC 5988 [2]. That began life many years ago 
when Mark Nottingham wanted to bring back the HTTP Link Header (formally).


The formal definition of wdrs:describedby is at [3] and it says:

The relationship A 'describedby' B asserts that resource B provides a 
description of resource A. There are no constraints on the format or 
representation of either A or B, neither are there any further 
constraints on either resource.


You can use it as the RDF property but it has /exactly/ the same 
semantics as the link relationship that we put into the ATOM registry 
initially and is now included in RFC 5988. In other words these three 
are equivalent (by design)


HTTP
Link: /doc; rel=describedby type=foo/bar;

HTML
link rel=describedby href=/doc type=foo/bar

RDF
 wdrs:describedby /doc

This morning I've been mulling over the idea of suggesting a new MIME 
type that says the thing you've asked for isn't an information 
resource and that /might/ help us out of a double round trip to find 
RDF about such a thing but even that doesn't really get us past the fact 
that 200 means here's a representation of what you asked for. If I 
dereference a URI that identifies beer and it says 200 OK - I at least 
expect to be able to drink it, not read about it.


Phil.

[1] http://philarcher.org/diary/303/
[2] http://tools.ietf.org/html/rfc5988
[3] http://www.w3.org/TR/powder-dr/#appD



On 05/11/2010 00:58, Kingsley Idehen wrote:

All,

So when all is said an done, post 303 redirection imbroglio, the moral
of the story *seems* to read as follows:

When you make a hypermedia based Ontology for deployment on an HTTP
network (intranet, extranet, World Wide Web) do include a relation that
associates it with the Properties and Classes that it describes.
Commonly used predicate for this is: rdfs:isDefinedBy [1] .

When you create hypermedia based structured data for deployment on an
HTTP network (intranet, extranet, World Wide Web) do include a relation
that associates each Subject/Entity (or Data Item) with its
container/host document. A suitable predicate for this is:
wdrs:describedBy [2] .

At the current time, most ontologies deployed on the Web do not include
rdfs:isDefinedBy triples. The same applies to descriptor documents (RDF
included) currently deployed on the Web re. wdrs:isDescribeBy.

As a best practice, common use of these predicates would increase
navigability, link density, and overall cohesiveness of the burgeoning
Web of Linked Data. It would truly demonstrate practicing what we
preach, dog-food style!


Links:

1. http://www.w3.org/2007/05/powder-s#describedBy
2. http://www.w3.org/TR/rdf-schema/#ch_isdefinedby.



--

Regards,

Kingsley Idehen
President  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen







Please consider the environment before printing this email.

Find out more about Talis at http://www.talis.com/
shared innovation™

Any views or personal opinions expressed within this email may not be
those of Talis Information Ltd or its employees. The content of this
email message and any files that may be attached are confidential, and
for the usage of the intended recipient only. If you are not the
intended recipient, then please return this message to the sender and
delete it. Any use of this e-mail by an unauthorised recipient is
prohibited.

Talis Information Ltd is a member of the Talis Group of companies and is
registered in England No 3638278 with its registered office at Knights
Court, Solihull Parkway, Birmingham Business Park, B37 7YB.



--


Phil Archer
Talis Platform
Web: http://www.talis.com
Tel: +44 1473 434770
Twitter: philarcher1
LinkedIn: http://uk.linkedin.com/in/philarcher
Personal: http://philarcher.org


Talis Systems Ltd,
Knights Court
Solihull Parkway
Birmingham Business Park
B37 7YB
United Kingdom

Tel: +44 (0)870 400 5000

wdrs Error (was Re: isDefinedBy and isDescribedBy, Tale of two missing predicates)

Forwarding my own message, this time from my w3.org address so it 
reaches the list.


Adding Public POWDER list. Main thread is on
http://lists.w3.org/Archives/Public/public-lod/2010Nov/

It's clear to me that there is an error in wdrs:describedby. And since I 
am one of the originators of it, I'd like to do something about it.


What I wrote, and meant, in the text at [1] was:
... [wdrs:describedby] is a generic relationship type that does not of
itself imply that the link points to a POWDER document — that is done by 
the specific Media type. The formal definition of describedby is given 
in Appendix D.


Appendix D is where it says:

The relationship A 'describedby' B asserts that resource B provides a
description of resource A. There are no constraints on the format or
representation of either A or B, neither are there any further
constraints on either resource.

However, later in the same document, at [2] it says

We define the RDF property wdrs:describedby with a domain of
rdf:Resource and a range of wdrs:Document. This is the class of POWDER
documents and is a sub class of owl:Ontology. The meaning of
wdrs:describedby is identical to the describedby relationship type
defined above so that:

http://www.w3.org/2007/05/powder-s#describedby

and

http://www.iana.org/assignments/relation/describedby

So we have a mis-match Either wdrs:describedby has a range of
wdrs:Document (bad) or it has the same semantics as the @rel type
describedby which implies no range at all (good).

I'd like to correct this error!! wdrs:describedby is intended to be used
exactly as is being discussed here - a generic link between A and B such
that B describes A with no constraints at all on either.

Since I can (readily) point to an error in the description of what I
hope is a basically sound design, I'm going to see if I can:

a) add an erratum to the POWDER Rec
b) edit the wdrs namespace documentation

That should I hope, make wdrs:describedby fully usable??

(Looks up W3C process document on getting this done...)

Phil

[1] http://www.w3.org/TR/powder-dr/#assoc-linking
[2] http://www.w3.org/TR/powder-dr/#semlink

On 05/11/2010 12:35, Dave Reynolds wrote:

On Fri, 2010-11-05 at 07:19 -0400, Kingsley Idehen wrote:

On 11/5/10 4:51 AM, Dave Reynolds wrote:

On Thu, 2010-11-04 at 20:58 -0400, Kingsley Idehen wrote:


When you create hypermedia based structured data for deployment on an
HTTP network (intranet, extranet, World Wide Web) do include a
relation that associates each Subject/Entity (or Data Item) with its
container/host document. A suitable predicate for this is:
wdrs:describedBy [2] .

Ian mentioned this predicate in his post.

Looking at [1] the range of wdrs:describeBy is given as class of POWDER
documents and is a sub class of owl:Ontology which seems to make it
unsuitable as a general predicate for the purpose being discussed here.

Dave

[1] http://www.w3.org/TR/powder-dr/#semlink





Dave,

I am not saying or implying that Ian didn't say this in his post.
These issues have been raised many times in the past by others
(including myself), repeatedly.


Indeed.

I was only responding on the specific suggestion to use wdrs, not
intending any broader comment.


Here's the key difference though, yesterday was the first time that
these suggestions were presented as somehow being mutually exclusive
relative to use of 303 redirection.

I don't want to start another session with Ian, but here is my
fundamental issue:
Fixing RDF resources doesn't have to be at the expense of 303
redirection (mechanism for resolve. At the end of the day there are
going to be resolvable object/entity identifiers either side of these
predicates, if we are seeking to keep the resulting Linked Data mesh
intact etc..

dropping 303 simply didn't need to be the focal point of the
conversation. It has nothing to do with why people have been
publishing old school RDF resources that fail to link the container
(rdf doc) with its structured content (triples).

I hope I've made my point clear :-)


Yes but I don't think the proposal was to ban use of 303 but to add an
alternative solution, a third way :)

I have some sympathy with this. The situation I've faced several times
of late is roughly this:

Reasonable and technically skilled person new to linked data reviews the
field with the intention of trying it out and concludes:

(a) Separating URIs for Things[0] and URIs for Documents containing
assertions (data, descriptions, attribute values, whatever) about those
things make sense [1].

(b) I want my Thing URIs to resolve but I don't want to use # URIs for
reasons foo/bar/baz [2].

(c) The Tag finding [3] means that we cannot use slash URIs for Things
unless we include a 303 redirect.

(d) Ergo we must use 303.

(e) Whoops this use of 303 is proving to be a barrier to adoption for my
users, maybe I'll switch to an easier technology [4].

Clearly simply using # URIs solves this but people can be surprisingly
reluctant to go that route.

I take this

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

2010-11-05 Thread Leigh Dodds

Hi,

On 5 November 2010 12:43, Nathan nat...@webr3.org wrote:
 Dave Reynolds wrote:

 Clearly simply using # URIs solves this but people can be surprisingly
 reluctant to go that route.

 Why? I still don't understand the reluctance, any info on the technical
 non-made-up-pedantic reasons would be great.

Dave provided a pointer to TimBL's discussion which had some comments,
there's also some brief discussion of the technical issues in the Cool
URIs paper, see [1]

[1]. http://www.w3.org/TR/cooluris/#choosing

Cheers,

L.

-- 
Leigh Dodds
Programme Manager, Talis Platform
Talis
leigh.do...@talis.com
http://www.talis.com

RE: isDefinedBy and isDescribedBy, Tale of two missing predicates

2010-11-05 Thread bill.roberts

Nathan

One practical downside of hash URIs that I've come across is this:

Suppose I have a resource http://example.com#foo

I can provide a description of it at http://example.com - so far so good.

If someone then asks me about http://example.com#bar - for whatever reason - 
but in fact I don't know anything about that identifier, in the sense that I 
don't have any statements about it in my triple store.  I'd like to tell that 
fact to the user - by returning 404 say,  but in fact my only option is to 
return the description of a different resource http://example.com#foo.  It 
won't be wrong, but it's a bit like saying describe Paris to me and getting 
the answer well Milan is very nice this time of year.

It's not the end of the world and you can work round it with conventions - for 
example by always using the same hash fragment of #thing etc

By the way, I like the hash fragment approach for ontologies, concept schemes 
etc and tend to use them in that context.

Sorry don't really want to derail this discussion into a hash vs slash rehash 
:-)

Bill



-Original Message-
From: public-lod-requ...@w3.org on behalf of Nathan
Sent: Fri 11/5/2010 1:43 PM
To: Dave Reynolds
Cc: Kingsley Idehen; public-lod@w3.org
Subject: Re: isDefinedBy and isDescribedBy, Tale of two missing predicates
 
Dave Reynolds wrote:
 Clearly simply using # URIs solves this but people can be surprisingly
 reluctant to go that route.

Why? I still don't understand the reluctance, any info on the technical 
non-made-up-pedantic reasons would be great.

Best,

Nathan

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

2010-11-05 Thread Vasiliy Faronov

Hi Phil,

Since you discuss HTTP status codes and their definitions, I just wanted
to point out that the current drafts of HTTPbis (i.e. the upcoming
revision of the HTTP spec) include a definition[1] for 303 specifically
tailored to the way it's used in LD today.

(There was also a long, philosophical thread[2] on www-tag some time ago
where the merits and shortcomings of this change were heavily debated.)

[1]
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#section-8.3.4
[2] http://lists.w3.org/Archives/Public/www-tag/2009Jul/thread.html#msg2

-- 
Vasiliy Faronov

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates


Leigh Dodds wrote:

On 5 November 2010 12:43, Nathan nat...@webr3.org wrote:

Dave Reynolds wrote:

Clearly simply using # URIs solves this but people can be surprisingly
reluctant to go that route.

Why? I still don't understand the reluctance, any info on the technical
non-made-up-pedantic reasons would be great.


Dave provided a pointer to TimBL's discussion which had some comments,
there's also some brief discussion of the technical issues in the Cool
URIs paper, see [1]

[1]. http://www.w3.org/TR/cooluris/#choosing


Thanks Leigh!

Analysis:

TimBLs Discussion [1]

  some people wanting to use RDF for large systems found that they
  didn't want to use the #. This was sometimes because the number
  of things defined in the same file was too low (like 1) or too large
  (like a million) and it was difficult to divide up the information
  into middle-sized chunks. Or they just didn't like the # because
  it looks weird.

The first reason is moot because you can have a single frag uri in a 
single document, a million, or middle sized document. If the point was 
more that if you have a million #frag's in a single doc and you want to 
refactor that in to several docs, then (1) you can, just assert it so in 
rdf, and (2) don't do that in the first place.

The second reason isn't a reason.

Cool URIs

  A client interested only in #product123 will inadvertently load the
  data for all other resources as well, because they are in the same
  file.

could also be seen as an advantage, especially in a follow your nose web.

Nothing else is listed, only very valid technical arguments against 303s 
and the negative impacts of using them.


Any advance?

[1] http://lists.w3.org/Archives/Public/www-tag/2009Aug/.html

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates


Thanks very much Vasily.

That's very helpful and makes it easy and right to stick with 303 IMO.

I was on the TAG and HTTP BIS mailing lists for a long time but had to 
unsubscribe due to all the discussions, mostly about this and metadata 
discovery, that kept distracting me ;-)


Cheers

Phil.

On 05/11/2010 13:47, Vasiliy Faronov wrote:

Hi Phil,

Since you discuss HTTP status codes and their definitions, I just wanted
to point out that the current drafts of HTTPbis (i.e. the upcoming
revision of the HTTP spec) include a definition[1] for 303 specifically
tailored to the way it's used in LD today.

(There was also a long, philosophical thread[2] on www-tag some time ago
where the merits and shortcomings of this change were heavily debated.)

[1]
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#section-8.3.4
[2] http://lists.w3.org/Archives/Public/www-tag/2009Jul/thread.html#msg2



--


Phil Archer
Talis Platform
Web: http://www.talis.com
Tel: +44 1473 434770
Twitter: philarcher1
LinkedIn: http://uk.linkedin.com/in/philarcher
Personal: http://philarcher.org


Talis Systems Ltd,
Knights Court
Solihull Parkway
Birmingham Business Park
B37 7YB
United Kingdom

Tel: +44 (0)870 400 5000

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

2010-11-05 Thread Norman Gray


On 2010 Nov 5, at 13:49, Nathan wrote:

  If the point was more that if you have a million #frag's in a single doc and 
 you want to refactor that in to several docs, then (1) you can, just assert 
 it so in rdf, and (2) don't do that in the first place.

I don't think this argument works.

I spend a little time recently LODifying an existing database (no link here, 
because it was experimental and hasn't been released).  That database has 14M 
identifiers in it, referring to nearly 5M objects, each of which has 
potentially quite a lot of information associated with it. 

I want them all to have URI names on the same pattern (this seems reasonable, 
and seems to preclude any partitioning of the dataset).  Using hash-URIs for 
these would effectively result in me sending the whole database to anyone who 
asked about any one object within it, which would surely be regarded as rather 
user-hostile.  No?

Hence slash-URIs in this case.

Best wishes,

Norman


-- 
Norman Gray  :  http://nxg.me.uk

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

2010-11-05 Thread Norman Gray


Nathan, hello.

On 2010 Nov 5, at 14:31, Nathan wrote:

 No, using hash URIs would certainly not mean that at all!!
 
 Use the URI pattern you wanted to use and stick #i or something at the end of 
 each one. Hash URIs *do not* mean you put everything in one document, it 
 simply means that you have one identifier for the doc and one for each thing 
 described within it, whether you put 1, 10 or 100 things in the doc.

OoooK -- I see.  Thanks for that clarification.

When I see the hash-URI pattern, I think of the pattern described in 
http://www.w3.org/TR/cooluris/#hashuri, which (as I understand it) is what I 
was effectively describing.  There, http://example.com/about#alice is the 
name for alice, and that is described along with a lot of other objects in the 
IR http://example.com/about.  As the authors there discuss it, this is better 
for 'small' sets of names, whereas the slash URI pattern as described there 
is better for larger ones.

The pattern you're describing (I don't know -- a hash-slash-URI?, which has one 
IR per NIR) has a distinct sets of tradeoffs, I think, but has the particular 
advantage that, if every NIR has a hash in it, then the IR/NIR distinction can 
be maintained without any status code gymnastics.

Best wishes,

Norman


-- 
Norman Gray  :  http://nxg.me.uk

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

2010-11-05 Thread Mischa Tuffield

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 5 Nov 2010, at 15:07, Norman Gray wrote:

 
 Nathan, hello.
 
 On 2010 Nov 5, at 14:31, Nathan wrote:
 
 No, using hash URIs would certainly not mean that at all!!
 
 Use the URI pattern you wanted to use and stick #i or something at the end 
 of each one. Hash URIs *do not* mean you put everything in one document, it 
 simply means that you have one identifier for the doc and one for each thing 
 described within it, whether you put 1, 10 or 100 things in the doc.
 
 OoooK -- I see.  Thanks for that clarification.
 
 When I see the hash-URI pattern, I think of the pattern described in 
 http://www.w3.org/TR/cooluris/#hashuri, which (as I understand it) is what 
 I was effectively describing.  There, http://example.com/about#alice is the 
 name for alice, and that is described along with a lot of other objects in 
 the IR http://example.com/about.  As the authors there discuss it, this is 
 better for 'small' sets of names, whereas the slash URI pattern as 
 described there is better for larger ones.
 
 The pattern you're describing (I don't know -- a hash-slash-URI?, which has 
 one IR per NIR) has a distinct sets of tradeoffs, I think, but has the 
 particular advantage that, if every NIR has a hash in it, then the IR/NIR 
 distinction can be maintained without any status code gymnastics.

Indeed, I think I eluded to this in my email to the 303 thread. The idea is 
to have smaller more manageable RDF documents on the web, IMHO targeted 
documents are more interesting than ones which talk about a million and one 
things. Again, I will try and draw an analogy here; at is stands, sites like 
the BBC, have one document per story, there is nothing stopping the BBC from 
having one page will all of its content on it, i.e. with each article having 
its own #fragment, but it is a lot neater to have a document per story. 

Regards,

Mischa


 Best wishes,
 
 Norman
 
 
 -- 
 Norman Gray  :  http://nxg.me.uk
 
 

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)

iQIcBAEBAgAGBQJM1B8MAAoJEJ7QsE5R8vfvMeEP/RhFsBt068LPKLqkeJakkngx
I3/r+J7y9bZJ5DYh7ycTrIo9dcCZ9Up+X6QkQMJYfevOVQWlh4RJnkBrUeQ3YVEc
lJVZw0Q7mzl2J3uNlyki5RBO0VZAc+23Cvf0o84+lPWMVdhWxC7FHI4ih2p7fiKa
1OmVMyb3IlXmQMdf284ujHhCosMpjm89FoSGQvJObq2UES/au9b/xjWv/KEl+1Qx
S35KeWz4i5GPQnTLxz53zEMaxV0aGS46UrR0Ko9MaFjApuf50ucDIvPxOCiJNLQa
c2GmpHiPFirlHzX1Cm+Fs04lC+4nM1SiJAM7JzsL5CLFUbJ6DGVt4cXZUl5boB7k
f+ykJNd7BycDqlXPQr1rTAaouD9gnA0OLpQ+gBY2Lf8Q+9MUS3XZHDaNDS0gQhuY
g2A/w4XyttDu1S0NilZAKcVOWOPhzBJEecF0Tc7YY7TVXnBrGvqufimxr9DsMjgQ
YLB3MT5GxYWdUZowXidTSMpTuUbDw5J0bTcASm2ud6qLVFyXrwry++Z6CTOIS8ge
1wqtbyOZk0+CPZfBzpGVwNZJ4d6r9yAhEoyY3etNCT+11GEngW+rAHBtzMY8t4II
9xqkUalPI3ZSooSnDID3p4o/BTGBeMDBAqz15hQvSYGiO9Fo7m2tGwSCfsAVDISI
FIA7rs7YLfTfJAcAiKW7
=dYpD
-END PGP SIGNATURE-

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates


On 11/5/10 8:35 AM, Dave Reynolds wrote:

On Fri, 2010-11-05 at 07:19 -0400, Kingsley Idehen wrote:

On 11/5/10 4:51 AM, Dave Reynolds wrote:

On Thu, 2010-11-04 at 20:58 -0400, Kingsley Idehen wrote:


When you create hypermedia based structured data for deployment on an
HTTP network (intranet, extranet, World Wide Web) do include a
relation that associates each Subject/Entity (or Data Item) with its
container/host document. A suitable predicate for this is:
wdrs:describedBy [2] .

Ian mentioned this predicate in his post.

Looking at [1] the range of wdrs:describeBy is given as class of POWDER
documents and is a sub class of owl:Ontology which seems to make it
unsuitable as a general predicate for the purpose being discussed here.

Dave

[1] http://www.w3.org/TR/powder-dr/#semlink





Dave,

I am not saying or implying that Ian didn't say this in his post.
These issues have been raised many times in the past by others
(including myself), repeatedly.

Indeed.

I was only responding on the specific suggestion to use wdrs, not
intending any broader comment.


Here's the key difference though, yesterday was the first time that
these suggestions were presented as somehow being mutually exclusive
relative to use of 303 redirection.

I don't want to start another session with Ian, but here is my
fundamental issue:
Fixing RDF resources doesn't have to be at the expense of 303
redirection (mechanism for resolve. At the end of the day there are
going to be resolvable object/entity identifiers either side of these
predicates, if we are seeking to keep the resulting Linked Data mesh
intact etc..

dropping 303 simply didn't need to be the focal point of the
conversation. It has nothing to do with why people have been
publishing old school RDF resources that fail to link the container
(rdf doc) with its structured content (triples).

I hope I've made my point clear :-)

Yes but I don't think the proposal was to ban use of 303 but to add an
alternative solution, a third way :)

Dave,

I have no issue with options.

My only gripe is with mutual exclusion. ..dropping 303... didn't come 
across as adding an option to the mix. Ditto positioning 303 as a 
mandate, which it's never really been.

I have some sympathy with this. The situation I've faced several times
of late is roughly this:

Reasonable and technically skilled person new to linked data reviews the
field with the intention of trying it out and concludes:

(a) Separating URIs for Things[0] and URIs for Documents containing
assertions (data, descriptions, attribute values, whatever) about those
things make sense [1].

(b) I want my Thing URIs to resolve but I don't want to use # URIs for
reasons foo/bar/baz [2].

(c) The Tag finding [3] means that we cannot use slash URIs for Things
unless we include a 303 redirect.

(d) Ergo we must use 303.

(e) Whoops this use of 303 is proving to be a barrier to adoption for my
users, maybe I'll switch to an easier technology [4].


Yes, which is why we've opted to move the conversation to the conceptual 
realm so that platforms take responsibility for complex Linked Data 
deployment while RDFa handles the magic document scenario i.e. use 
HTML+RDFa to create data descriptions, inject into the Web via a myriad 
routes i.e., no Apache and .htaccess tax etc..


What Facebook, Microsoft, and Google take the position that 
high-semantic-fidelity EAV graphs are best handled by organizations that 
are capable of transforming their low-semantic-fidelity EAV graphs. Of 
course, they hold this position today because the opportunity costs to 
their respective organizations aren't palpable just yet. That's going to 
change, and change quick if Linked Data platforms just deliver Linked 
Data without the distraction element of RDF.


Google's adoption of RDFa is a nice example of what I've outlined above. 
Google is no stranger to RDF, they just haven't been able to get past 
its legacy problems. Then along comes RDFa + GoodRelations, totally 
about opportunity cost palpability and 12 months later, they 
officially come out, because in reality they had no choice. It now makes 
sense re. palpable impact on short and long term business model. Sames 
has also happened at Yahoo!, and in a sense Facebook.

Clearly simply using # URIs solves this but people can be surprisingly
reluctant to go that route.


Sorta.  Ultimately, we are going to be stuck with a variety of 
approaches. Platforms should solve these problems, users should just 
exploit the virtues of Linked Data.

I take this discussion to be exploring the question:

 Would a third alternative be possible?  People can continue to
 use # URIs and to use slash URIs with 303s but would it be that
 bad if we allowed people to use slash URIs for Things, without
 the redirect?

The talk of dropping and deprecating I've heard has been concerned
with the TAG finding on http-range-14 (which does ban use of slash URIs
for Things and thus is a genuine,

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

2010-11-05 Thread Ian Davis

Kingsley,

 My only gripe is with mutual exclusion. ..dropping 303... didn't come
 across as adding an option to the mix. Ditto positioning 303 as a mandate,
 which it's never really been.

I think you read too much conspiracy into 140 characters.

Ian

Re: wdrs Error (was Re: isDefinedBy and isDescribedBy, Tale of two missing predicates)


On 11/5/10 8:58 AM, Phil Archer wrote:
Adding Public POWDER list. Main thread is on 
http://lists.w3.org/Archives/Public/public-lod/2010Nov/


It's clear to me that there is an error in wdrs:describedby. And since 
I am one of the originators of it, I'd like to do something about it.


What I wrote, and meant, in the text at [1] was:
... [wdrs:describedby] is a generic relationship type that does not 
of itself imply that the link points to a POWDER document — that is 
done by the specific Media type. The formal definition of describedby 
is given in Appendix D.


Appendix D is where it says:

The relationship A 'describedby' B asserts that resource B provides a 
description of resource A. There are no constraints on the format or 
representation of either A or B, neither are there any further 
constraints on either resource.


However, later in the same document, at [2] it says

We define the RDF property wdrs:describedby with a domain of 
rdf:Resource and a range of wdrs:Document. This is the class of POWDER 
documents and is a sub class of owl:Ontology. The meaning of 
wdrs:describedby is identical to the describedby relationship type 
defined above so that:


http://www.w3.org/2007/05/powder-s#describedby

and

http://www.iana.org/assignments/relation/describedby

So we have a mis-match Either wdrs:describedby has a range of 
wdrs:Document (bad) or it has the same semantics as the @rel type 
describedby which implies no range at all (good).




Phil,

We've always implemented in  good faith :-)

I'd like to correct this error!! wdrs:describedby is intended to be 
used exactly as is being discussed here - a generic link between A and 
B such that B describes A with no constraints at all on either.


The specs do need to be fixed, as there is a tsunami heading POWDER's way.


Since I can (readily) point to an error in the description of what I 
hope is a basically sound design, I'm going to see if I can:


a) add an erratum to the POWDER Rec
b) edit the wdrs namespace documentation

That should I hope, make wdrs:describedby fully usable??


Great!


Kingsley


(Looks up W3C process document on getting this done...)

Phil

[1] http://www.w3.org/TR/powder-dr/#assoc-linking
[2] http://www.w3.org/TR/powder-dr/#semlink

On 05/11/2010 12:35, Dave Reynolds wrote:

On Fri, 2010-11-05 at 07:19 -0400, Kingsley Idehen wrote:

On 11/5/10 4:51 AM, Dave Reynolds wrote:

On Thu, 2010-11-04 at 20:58 -0400, Kingsley Idehen wrote:


When you create hypermedia based structured data for deployment on an
HTTP network (intranet, extranet, World Wide Web) do include a
relation that associates each Subject/Entity (or Data Item) with its
container/host document. A suitable predicate for this is:
wdrs:describedBy [2] .

Ian mentioned this predicate in his post.

Looking at [1] the range of wdrs:describeBy is given as class of 
POWDER

documents and is a sub class of owl:Ontology which seems to make it
unsuitable as a general predicate for the purpose being discussed 
here.


Dave

[1] http://www.w3.org/TR/powder-dr/#semlink





Dave,

I am not saying or implying that Ian didn't say this in his post.
These issues have been raised many times in the past by others
(including myself), repeatedly.


Indeed.

I was only responding on the specific suggestion to use wdrs, not
intending any broader comment.


Here's the key difference though, yesterday was the first time that
these suggestions were presented as somehow being mutually exclusive
relative to use of 303 redirection.

I don't want to start another session with Ian, but here is my
fundamental issue:
Fixing RDF resources doesn't have to be at the expense of 303
redirection (mechanism for resolve. At the end of the day there are
going to be resolvable object/entity identifiers either side of these
predicates, if we are seeking to keep the resulting Linked Data mesh
intact etc..

dropping 303 simply didn't need to be the focal point of the
conversation. It has nothing to do with why people have been
publishing old school RDF resources that fail to link the container
(rdf doc) with its structured content (triples).

I hope I've made my point clear :-)


Yes but I don't think the proposal was to ban use of 303 but to add an
alternative solution, a third way :)

I have some sympathy with this. The situation I've faced several times
of late is roughly this:

Reasonable and technically skilled person new to linked data reviews the
field with the intention of trying it out and concludes:

(a) Separating URIs for Things[0] and URIs for Documents containing
assertions (data, descriptions, attribute values, whatever) about those
things make sense [1].

(b) I want my Thing URIs to resolve but I don't want to use # URIs for
reasons foo/bar/baz [2].

(c) The Tag finding [3] means that we cannot use slash URIs for Things
unless we include a 303 redirect.

(d) Ergo we must use 303.

(e) Whoops this use of 303 is proving to be a barrier to adoption for my
users, maybe I'll switch to an easier

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates


Ian Davis wrote:

On Fri, Nov 5, 2010 at 1:49 PM, Nathan nat...@webr3.org wrote:


Any advance?


I've written on it extensively and linked to two pieced in my recent
303 blog post:

http://iand.posterous.com/2007/11/fragmentation-reprise


  The core of the problem is that hashed URIs are inherently ambiguous.
  Its meaning depends on how you access it, which is nuts. Its as though
  a word has different meanings depending on whether you read it in a
  book or have it read out to you.

No the meaning of any RDF URI Reference is the meaning which you give to 
it by making statements which include it, it's just a logical constant, 
a name.



http://iand.posterous.com/2007/11/its-ok-to-use-uris-with-fragments-in-rdf


sigh, in to the depths of pedantic serialization specific minor age old 
issues which have never been proven to affect anything really we go:


  ... further away from today's web of documents. For example, when I
  use http://www.w3.org/TR/webarch/#media-type-fragid; as a URI in my
  RDF, it probably doesn't refer to the thing you think it does. You, as
  a human (if you are), get to see a representation of that section of
  the document when you click on the link, but an RDF-aware agent must
  treat that URI as though rdf/xml had been retrieved.

Can you expand on what that means, because all I'm seeing is if an 
RDF-aware agent did treat that URI as though rdf/xml had been 
retrieved then it wouldn't have a description of the thing identified 
by http://www.w3.org/TR/webarch/#media-type-fragid == no problem.


  Unfortunately there isn't any RDF there and the Web Architecture
  actually forbids you from serving up both HTML and RDF documents at
  the same URI.

Better clear that up, noticed that it's an age old XHTML-RDFa potential 
issue, so I'll see if we can get it covered in the WG and relay back to 
the TAG to hopefully clear the issue.


AFAIK though, there is nothing stopping you from serving HTML and RDF 
documents at the same URI, in fact that would mean you can't serve up 
RDFa, which clearly is incorrect.


   How can RDF co-exist with other formats on the Web if it ignores
   their semantics?

Either you mean that RDF should be aware of the semantics of every media 
type on the web, or your saying that an RDF Graph should somehow be 
aware of something it's not aware of (it's just statements, names and 
literals) - or your making reference to the Generic processing of 
Fragment IDs in RFC 3023bis issue around rdf:ID.


Quite sure this doesn't affect any other serializations (since they're 
not XML based), so from that standpoint all of this is purely RDF/XML 
specific, and could be fixed / cleared.


Was hoping for something of more substance with some kind of real 
technical effect, not a path in to the depths of minor differences 
between various specifications published over a decade long time line 
tbh, something tangible.


Best,

Nathan

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

2010-11-05 Thread Ian Davis

On Fri, Nov 5, 2010 at 3:29 PM, Nathan nat...@webr3.org wrote:
 Better clear that up, noticed that it's an age old XHTML-RDFa potential
 issue, so I'll see if we can get it covered in the WG and relay back to the
 TAG to hopefully clear the issue.

Suppose I assign the ID 'mars' to represent the planet mars in my RDFa
document. I can then refer to it using http://example.com/foo#mars.
What does it mean when my javascript calls
document.getElementById('mars')? Should I expect now to manipulate the
planet mars?

This is an analagous dilemma as for slash URIs except the domain is
html + javascript rather than http.

Just like your claimed slash URI problems, in practice it is a
non-issue because people don't really expect to manipulate planets
with javascript. Some dumb machine might assume that in the future but
 they are going to make a lot of similar mistakes that will cause a
lot more problems.


Ian

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates


Ian Davis wrote:

On Fri, Nov 5, 2010 at 3:29 PM, Nathan nat...@webr3.org wrote:

Better clear that up, noticed that it's an age old XHTML-RDFa potential
issue, so I'll see if we can get it covered in the WG and relay back to the
TAG to hopefully clear the issue.


Suppose I assign the ID 'mars' to represent the planet mars in my RDFa
document. I can then refer to it using http://example.com/foo#mars.
What does it mean when my javascript calls
document.getElementById('mars')? Should I expect now to manipulate the
planet mars?


Ian..

See if you can find a mention of @id in either:
  http://www.w3.org/TR/rdfa-syntax/
  http://www.w3.org/TR/rdfa-core/

RDFa doesn't use @id.

However, to address the non existent issue as if it did exist.

HTML is an AST which encodes a DOM, the @id is an attribute which is to 
be applied to the DOM element in the DOM, in memory. User agents which 
use display the DOM use @id to reference the element, and via several 
forms of indirection they will often align the view of a document to the 
element with that @id if it's requested to do so. It so happens that 
User Agents will display this @id appended to the main document URI in 
the statues bar of the User Agent (possibly) when it does this. I can 
assure you, you've not just minted a URI.


As for javascript document.getElementById('mars'), as explain above all 
you're doing is pulling an object from memory which has an id attribute 
specified in an AST applied to it. How that relates to URIs or to us on 
the semantic web I'm unsure.


Now, let's just suppose that RDFa did use @id - well, what would happen 
is an RDFa processor would analyse the DOM document (not the HTML 
document, nor the AST) and when it found an @id it would combine the 
string lexical form of it, with the string lexical form of the relevant 
base, then create an IRI compatible RDF URI Reference out of it, then it 
would keep hunting down the DOM using the processing rules, and maybe it 
would find enough attributes to find a statement which is encoded in the 
document, this may comprise of other RDF URI References or Plain / 
Literals, and then finally you'll get some RDF to work with. You may 
notice that the RDF URI Reference isn't even in the document (HTML, AST 
or DOM) - and certainly isn't in the @id.


But remember, RDFa doesn't use @id, nor does HTML have RDF URI 
References in it ;)


Best,

Nathan

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates


On 11/5/10 11:19 AM, Ian Davis wrote:

Kingsley,


My only gripe is with mutual exclusion. ..dropping 303... didn't come
across as adding an option to the mix. Ditto positioning 303 as a mandate,
which it's never really been.

I think you read too much conspiracy into 140 characters.

Ian


Ian,

Not really, my biggest fear is the FUD onslaught to come (from outside 
the community), especially now that Linked Data is demonstrably hitting 
critical mass.


I think innovating behind the concept is better than innovating in front 
of it.


I (and I am sure you) want to have very simple discussions about Linked 
Data that veer (rapidly) to value proposition demonstration and 
crystallization. We can't get bogged down with mechanics, not in 2010. :-)



--

Regards,

Kingsley Idehen 
President  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

Norman Gray wrote:

Nathan, hello.

On 2010 Nov 5, at 14:31, Nathan wrote:

No, using hash URIs would certainly not mean that at all!!

Use the URI pattern you wanted to use and stick #i or something at the end of
each one. Hash URIs *do not* mean you put everything in one document, it simply
means that you have one identifier for the doc and one for each thing described
within it, whether you put 1, 10 or 100 things in the doc.

OoooK -- I see. Thanks for that clarification.

When I see the hash-URI pattern, I think of the pattern described in
http://www.w3.org/TR/cooluris/#hashuri, which (as I understand it) is what I was effectively describing.
There, http://example.com/about#alice is the name for alice, and that is described along with a lot of other
objects in the IR http://example.com/about. As the authors there discuss it, this is better for 'small' sets
of names, whereas the slash URI pattern as described there is better for larger ones.

Whoops, if that's what COOL is inferring then that's probably a bug
which needs addressed, Richard can you clarify / let us know if it's
possible to do anything with COOL (maybe even update and republish?)

The pattern you're describing (I don't know -- a hash-slash-URI?, which has one
IR per NIR) has a distinct sets of tradeoffs, I think, but has the particular
advantage that, if every NIR has a hash in it, then the IR/NIR distinction can
be maintained without any status code gymnastics.

Well, the pattern I'm describing is whatever you want it to be - pick a
URI pattern that suits you and doesn't have the trade offs, just use
/slash for docs and #frags for things. You can put the description of 3
things in one doc, or one doc per thing, or whatever suits logically to
be both HTTP friendly, provide a full description of that which you are
describing, and with suitable granularity that you can't for see
document size becoming an issue.

However, even if document size ever does become an issue (because the
description of the thing or things is too big) then you can use the
link:listDocumentProperty approach as described in the Linked Data
Design Issue [1] to factor properties of a certain type in to a
different doc.

[1] http://www.w3.org/DesignIssues/LinkedData.html

Best,

Nathan

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

Mischa Tuffield wrote:

On 5 Nov 2010, at 15:07, Norman Gray wrote:

Nathan, hello.

On 2010 Nov 5, at 14:31, Nathan wrote:

No, using hash URIs would certainly not mean that at all!!

OoooK -- I see. Thanks for that clarification.

Indeed, I think I eluded to this in my email to the 303 thread. The idea is to have smaller more manageable RDF documents on the web, IMHO targeted documents are more interesting than ones which talk about a million and one things. Again, I will try and draw an analogy here; at is stands, sites like the BBC, have one document per story, there is nothing stopping the BBC from having one page will all of its content on it, i.e. with each article having its own #fragment, but it is a lot neater to have a document per story.

I don't follow why it's inferred here that if you use a fragment then
all information must be in one document?? makes no sense. You can use
exactly the same one article per document approach with frags.

Best,

Nathan

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

2010-11-05 Thread Mischa Tuffield

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 5 Nov 2010, at 16:42, Nathan wrote:

 Mischa Tuffield wrote:
 On 5 Nov 2010, at 15:07, Norman Gray wrote:
 Nathan, hello.
 
 On 2010 Nov 5, at 14:31, Nathan wrote:
 
 No, using hash URIs would certainly not mean that at all!!
 
 Use the URI pattern you wanted to use and stick #i or something at the end 
 of each one. Hash URIs *do not* mean you put everything in one document, 
 it simply means that you have one identifier for the doc and one for each 
 thing described within it, whether you put 1, 10 or 100 things in the doc.
 OoooK -- I see.  Thanks for that clarification.
 
 When I see the hash-URI pattern, I think of the pattern described in 
 http://www.w3.org/TR/cooluris/#hashuri, which (as I understand it) is 
 what I was effectively describing.  There, http://example.com/about#alice 
 is the name for alice, and that is described along with a lot of other 
 objects in the IR http://example.com/about.  As the authors there discuss 
 it, this is better for 'small' sets of names, whereas the slash URI 
 pattern as described there is better for larger ones.
 
 The pattern you're describing (I don't know -- a hash-slash-URI?, which has 
 one IR per NIR) has a distinct sets of tradeoffs, I think, but has the 
 particular advantage that, if every NIR has a hash in it, then the IR/NIR 
 distinction can be maintained without any status code gymnastics.
 Indeed, I think I eluded to this in my email to the 303 thread. The idea 
 is to have smaller more manageable RDF documents on the web, IMHO targeted 
 documents are more interesting than ones which talk about a million and one 
 things. Again, I will try and draw an analogy here; at is stands, sites like 
 the BBC, have one document per story, there is nothing stopping the BBC from 
 having one page will all of its content on it, i.e. with each article having 
 its own #fragment, but it is a lot neater to have a document per story. 
 
 I don't follow why it's inferred here that if you use a fragment then all 
 information must be in one document?? makes no sense. You can use exactly the 
 same one article per document approach with frags.

Mmm, not at all. The point I was trying (and obviously failed) to make is, that 
if are not using #fragments because you feel that you will have a single 
document with way too many #fragments in it, you probably want to think about 
re-organising your data into more than document. 

Mischa

 
 Best,
 
 Nathan
 

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)

iQIcBAEBAgAGBQJM1DhJAAoJEJ7QsE5R8vfvodEP/jpYecHhz/z4JUcIz2cQGY69
ubZ3EYFVw+rgwvfwoIfmDIyJbhhCdFaTfch9/3q5MOR/ugb2CGr7aT4rPT0RtTnz
wPdrZDS7VUDQAmeFDY8pJJoOYpIj2wwBWL+sRyZV26D2efGrjB2IBPGYatO4WTIZ
ylgsxHv2qolWb+sReFw/5NZ1IAw0t3Qt43ajMoXxAMwjDeAlWkU7En+Vbh5gXpSv
Xa26lfi4DIhCN2jizrK6kX/c9MCWr6j+lYvfciw5jM7Pum13sKxW/pNneVshNBNQ
OR8okQmVxRT+LQI1sDVYbnI/mDEEZ2Dh9uPvzwEfVwn85ylRMKIETqMy+xcpMIp8
gvjlrSVNEcvGHm2t448G9H9R7Gfc184nIHXILKKniqYRDdJnnwuOioGg3CY3PGkD
2ePe7INuHPGS60DVd1DPNdbiKBC8F1GUNWQrRzLzDzrxY46XrKaIpxBePI23RbOS
ZQoUbfFCk7xEMeI0gWFbx+OXuRM1kMZuJImOEnq4NSAifdmA7ifs46ig9qnj4y/Y
sS+6zVhonMr4HeqPdVeUv9wSFPTBC6y6OSwN1R3h/UgFb7pV7YNwet9Nn6OH/Wom
TmmkGHhzQ8NvLZSpyRf1QQH9cD7pDQd9j+V7UgZ2oWIQDgKQWBWsdEB7hQOgknca
GqCzbFBgJ5m3CiheTDbd
=3Kw5
-END PGP SIGNATURE-

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

2010-11-05 Thread Hugh Glaser

Seems a good point to ask for some help my understanding.
I would guess I am about to display great ignorance here, but... :-)
My understanding of http://example.com/about#alice is that the
sub-application libraries (woolly terms, to include caches, etc.!) will
(must) fetch http://example.com/about as a page, and then do something
about the alice frag.
Later, if I ask for http://example.com/about#bob, and expiry etc. was
not set aggressively, then there is a distinct possibility that the page
will not be re-fetched, but just hand back the version: of
http://example.com/about that the server chose to return in response to
the http://example.com/about#alice request.
So if I have loads of frags in http://example.com/about, then if I don't
give them all every time, the consuming app can legitimately find that the
others, such as http://example.com/about#bob are not there?
Sorry if this is a question that everyone already knows the answer to.
Cheers
Hugh

On 05/11/2010 16:42, Nathan nat...@webr3.org wrote:

Mischa Tuffield wrote:
 On 5 Nov 2010, at 15:07, Norman Gray wrote:
 
 Nathan, hello.

 On 2010 Nov 5, at 14:31, Nathan wrote:

 No, using hash URIs would certainly not mean that at all!!

 Use the URI pattern you wanted to use and stick #i or something at
the end of each one. Hash URIs *do not* mean you put everything in one
document, it simply means that you have one identifier for the doc and
one for each thing described within it, whether you put 1, 10 or 100
things in the doc.
 OoooK -- I see.  Thanks for that clarification.

 When I see the hash-URI pattern, I think of the pattern described in
http://www.w3.org/TR/cooluris/#hashuri, which (as I understand it) is
what I was effectively describing.  There,
http://example.com/about#alice is the name for alice, and that is
described along with a lot of other objects in the IR
http://example.com/about.  As the authors there discuss it, this is
better for 'small' sets of names, whereas the slash URI pattern as
described there is better for larger ones.

 The pattern you're describing (I don't know -- a hash-slash-URI?,
which has one IR per NIR) has a distinct sets of tradeoffs, I think,
but has the particular advantage that, if every NIR has a hash in it,
then the IR/NIR distinction can be maintained without any status code
gymnastics.
 
 Indeed, I think I eluded to this in my email to the 303 thread. The
idea is to have smaller more manageable RDF documents on the web, IMHO
targeted documents are more interesting than ones which talk about a
million and one things. Again, I will try and draw an analogy here; at
is stands, sites like the BBC, have one document per story, there is
nothing stopping the BBC from having one page will all of its content on
it, i.e. with each article having its own #fragment, but it is a lot
neater to have a document per story.

I don't follow why it's inferred here that if you use a fragment then
all information must be in one document?? makes no sense. You can use
exactly the same one article per document approach with frags.

Best,

Nathan

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

2010-11-05 Thread Mischa Tuffield

Hugh, 

On 5 Nov 2010, at 17:11, Hugh Glaser wrote:

 Seems a good point to ask for some help my understanding.
 I would guess I am about to display great ignorance here, but... :-)
 My understanding of http://example.com/about#alice is that the
 sub-application libraries (woolly terms, to include caches, etc.!) will
 (must) fetch http://example.com/about as a page, and then do something
 about the alice frag.
 Later, if I ask for http://example.com/about#bob, and expiry etc. was
 not set aggressively, then there is a distinct possibility that the page
 will not be re-fetched, but just hand back the version: of
 http://example.com/about that the server chose to return in response to
 the http://example.com/about#alice request.
 So if I have loads of frags in http://example.com/about, then if I don't
 give them all every time, the consuming app can legitimately find that the
 others, such as http://example.com/about#bob are not there?
 Sorry if this is a question that everyone already knows the answer to.

Am not what you mean by if I don't give them all every time here. 

But FWIW if you curl http://example.com/foo#bar

or curl http://example.com/foo#foobar

you will get back the same document http://example.com/foo

Mischa

 Cheers
 Hugh
 
 On 05/11/2010 16:42, Nathan nat...@webr3.org wrote:
 
 Mischa Tuffield wrote:
 On 5 Nov 2010, at 15:07, Norman Gray wrote:
 
 Nathan, hello.
 
 On 2010 Nov 5, at 14:31, Nathan wrote:
 
 No, using hash URIs would certainly not mean that at all!!
 
 Use the URI pattern you wanted to use and stick #i or something at
 the end of each one. Hash URIs *do not* mean you put everything in one
 document, it simply means that you have one identifier for the doc and
 one for each thing described within it, whether you put 1, 10 or 100
 things in the doc.
 OoooK -- I see.  Thanks for that clarification.
 
 When I see the hash-URI pattern, I think of the pattern described in
 http://www.w3.org/TR/cooluris/#hashuri, which (as I understand it) is
 what I was effectively describing.  There,
 http://example.com/about#alice is the name for alice, and that is
 described along with a lot of other objects in the IR
 http://example.com/about.  As the authors there discuss it, this is
 better for 'small' sets of names, whereas the slash URI pattern as
 described there is better for larger ones.
 
 The pattern you're describing (I don't know -- a hash-slash-URI?,
 which has one IR per NIR) has a distinct sets of tradeoffs, I think,
 but has the particular advantage that, if every NIR has a hash in it,
 then the IR/NIR distinction can be maintained without any status code
 gymnastics.
 
 Indeed, I think I eluded to this in my email to the 303 thread. The
 idea is to have smaller more manageable RDF documents on the web, IMHO
 targeted documents are more interesting than ones which talk about a
 million and one things. Again, I will try and draw an analogy here; at
 is stands, sites like the BBC, have one document per story, there is
 nothing stopping the BBC from having one page will all of its content on
 it, i.e. with each article having its own #fragment, but it is a lot
 neater to have a document per story.
 
 I don't follow why it's inferred here that if you use a fragment then
 all information must be in one document?? makes no sense. You can use
 exactly the same one article per document approach with frags.
 
 Best,
 
 Nathan
 
 
 



PGP.sig
Description: This is a digitally signed message part

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

2010-11-05 Thread Norman Gray


Hugh (and Nathan), hello.

On 2010 Nov 5, at 17:11, Hugh Glaser wrote:

 Later, if I ask for http://example.com/about#bob, and expiry etc. was
 not set aggressively, then there is a distinct possibility that the page
 will not be re-fetched, but just hand back the version: of
 http://example.com/about that the server chose to return in response to
 the http://example.com/about#alice request.

Unless I'm misunderstanding you, if the client is asked find out about 
http://example.com/about#bob;, then it retrives the URL 
http://example.com/about -- the fragment is _not_ part of the request, and 
these two URI identifiers _both_ result in the same document being retrieved.  
Therefore, that /about document must describe both #bob and #alice.

Thus (Nathan), responding to

 I don't follow why it's inferred here that if you use a fragment then all 
 information must be in one document?? makes no sense. You can use exactly the 
 same one article per document approach with frags

...the http://www.w3.org/TR/cooluris/#hashuri example of the 
http://example.com/about#alice identifier implies that the 
http://example.com/about document must contain information about both the 
#alice and #bob fragments, because there's no way that the server can tell the 
difference between the two (since it never sees the fragment), and so it must 
provide the same document in both cases.

A variant of this is the one-identifier-per-document one that you're describing 
(if I understand you correctly).  You certainly can use the pattern 
http://example.com/about/alice#alice, and here the per-identifier document 
http://example.com/about/alice is an IR and the identifiers 
http://example.com/about/alice#alice or http://example.com/about/alice#i 
are not.

I can see the advantages of this latter slash-hash-URI scheme, but I'm fairly 
confident it's distinct from what Leo and Richard are describing as their 
hash-URI scheme.  If their hash-URI scheme is intended to cover your 
scheme, too, then the cooluris document may need a little clarification.

Best wishes,

Norman


-- 
Norman Gray  :  http://nxg.me.uk

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

Hi Norman,

Norman Gray wrote:

I don't follow why it's inferred here that if you use a fragment then all
information must be in one document?? makes no sense. You can use exactly the
same one article per document approach with frags

...the http://www.w3.org/TR/cooluris/#hashuri example of the
http://example.com/about#alice identifier implies that the
http://example.com/about document must contain information about both the #alice and #bob
fragments, because there's no way that the server can tell the difference between the two (since
it never sees the fragment), and so it must provide the same document in both cases.

A variant of this is the one-identifier-per-document one that you're describing (if I understand you
correctly). You certainly can use the pattern http://example.com/about/alice#alice, and here
the per-identifier document http://example.com/about/alice is an IR and the identifiers
http://example.com/about/alice#alice or http://example.com/about/alice#i are not.

I can see the advantages of this latter slash-hash-URI scheme, but I'm fairly confident it's
distinct from what Leo and Richard are describing as their hash-URI scheme. If their
hash-URI scheme is intended to cover your scheme, too, then the cooluris document may need a
little clarification.

Hmm, I don't see a distinction between the patterns to be honest,
Richard / Leo can verify if they are distinct, personally think it could
be better clarified to use a few different uris, some where it's one
resource per doc, some with more than one.

http://example.com/alice#me
http://example.com/about#bob
http://example.com/about#frank

for instance, or something even clearer.

Best,

Nathan

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates