More browsers for ISWC 2010 data?
Hi all, I added a few known data browsers that can work with ISWC 2010 data [1]. If you know other live demos that can browse/visualize the dataset, please expand the list, or let me know. [1] http://www.w3.org/2001/sw/wiki/ISWC_2010_Data_and_Demos#General-purpose_browsers_that_can_work_with_ISWC_data Cheers! Jie - Jie Bao Tetherless World Constellation Rensselaer Polytechnic Institute bao...@cs.rpi.edu http://www.cs.rpi.edu/~baojie
Re: Hash vs Slash in relation to the 303 vs 200 debate (was: Is 303 really necessary - demo)
On Sat, Nov 6, 2010 at 11:31 PM, Toby Inkster t...@g5n.co.uk wrote:
Not necessarily. If you take your ex:isDescribedBy predicate and add
that to a triple store where the non-Information-Resource resources are
identified using hash URIs, then the SPARQL query is just:
DESCRIBE uri ?res
WHERE { ?res ex:isDescribedBy uri . }
which needn't be very slow.
I've done this myself but using foaf:primaryTopic and foaf:topic to
link a document URI to all the resources that are needed to render it.
The other downside of fragments is you can't say it exists but I have
no description of it.
#foo a rdfs:Resource .
In which case you do have a description of it :) But point taken, this
tautology would be enough.
Cheers,
Ian
Re: 200 OK with Content-Location might work
+1 indeed. Content-Location has definitely been overlooked. During conneg, it is used to differ between a resource and its representation(s), which are obviously different resources (well, not necessarily the same). This distinction could certainly be enough to remove the fundamental need for 303:ing on NIR:s (provided consensus and some formal resolution). (I pondered on a similar issue in http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2010Feb/0007.html, regarding the identity of fragments. Perhaps that discussion would be worth revisiting again in light of this?) Best regards, Niklas On Fri, Nov 5, 2010 at 5:55 PM, Nathan nat...@webr3.org wrote: Mike Kelly wrote: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#page-14 snipped and fuller version inserted: 4. If the response has a Content-Location header field, and that URI is not the same as the effective request URI, then the response asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by HTTP). If a client wants to make a statement about the specific document then a response that includes a content-location is giving you the information necessary to do that correctly. It's complemented and further clarified in the entity body itself through something like isDescribedBy. I stand corrected, think there's something in this, and it could maybe possibly provide the semantic indirection needed when Content-Location is there, and different to the effective request uri, and complimented by some statements (perhaps RDF in the body, or Link header, or html link element) to assert the same. Covers a few use-cases, might have legs (once HTTP-bis is a standard?). Nicely caught Mike! Best, Nathan
RE: [foaf-dev] EON - event of note
Hi Toby! For your information, the term EON is also used as the acronym of the International Workshop on Evaluation of Ontology-based Tools, an (almost-) yearly event that exists since 2002. See [1] for the proceedings of the first EON workshop. It would probably not be advisable to reuse the acronym for something else in the Semantic Web context. Michael [1] http://ceur-ws.org/Vol-62/ -Original Message- From: semantic-web-requ...@w3.org [mailto:semantic-web-requ...@w3.org] On Behalf Of Toby Inkster Sent: Sunday, November 07, 2010 12:43 AM To: public-lod@w3.org; semantic-...@w3.org Subject: Fw: [foaf-dev] EON - event of note Begin forwarded message... Date: Thu, 4 Nov 2010 00:32:50 + From: Toby Inkster t...@g5n.co.uk To: foaf-dev foaf-...@lists.foaf-project.org Subject: [foaf-dev] EON - event of note Let's do a bit of collaborative work to flesh out a FOAF-like lightweight vocabulary for describing events, suitable for embedding in RDFa to describe concerts, conferences, birthdays, anniversaries, national holidays and so on. Sure, we have the iCalendar RDF vocab, but I've come to the conclusion that that's more suited to representing calendar entries - not the events themselves. I'm thinking of a simple set of extensions for Yves Raimond's Event Ontology. Let's kickstart this with the class eon:Event which would be a trivial subclass of http://purl.org/NET/c4dm/event.owl#Event. Here's a sketch of how an event might look in Turtle: #this a eon:Event ; foaf:name Lewes Bonfire ; foaf:page http://www.lewesbonfirecouncil.org.uk/ ; eon:date 2010-11-05^^xsd:date ; eon:location [ foaf:name Lewes ; foaf:page wikipedia:Lewes ] . Properties that I think should be included: * eon:start and eon:end - which can be xsd:dateTime or xsd:date (if the latter, then the event starts/ends at an unspecified time on that day) * eon:date - a subproperty of both eon:start and eon:end with range xsd:date. * eon:location - range geo:SpatialThing Probably need an attendee property and an organizer/participant property. Maybe eon:cost, eon:details, eon:bookings. I've placed a sketch on my data wiki http://wiki.ontologi.es/. Feel free to edit; and add yourself as a foaf:maker if you do! -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk -- Dipl.-Inform. Michael Schneider Research Scientist, Information Process Engineering (IPE) Tel : +49-721-9654-726 Fax : +49-721-9654-727 Email: michael.schnei...@fzi.de WWW : http://www.fzi.de/michael.schneider === FZI Forschungszentrum Informatik an der Universität Karlsruhe Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe Tel.: +49-721-9654-0, Fax: +49-721-9654-959 Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor, Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus ===
Re: [foaf-dev] EON - event of note
On Sunday 07 November 2010, Michael Schneider wrote: For your information, the term EON is also used as the acronym ... Not to mention these: http://en.wikipedia.org/wiki/Eon (So my first association was it's an event of E.ON, the energy company ;) ) Jörn
Re: 200 OK with Content-Location might work
Niklas,
In general I am supportive of your and Ian's thinking. 200 OK with
Content-Location might work.
However, three points from my perspective:
1) debating fundamental issues like this is very destabilising for those
of us looking to expand the LOD community and introduce new people and
organisations to Linked Data. To outsiders, it makes LOD seem like its
not ready for adoption and use - which is deadly. This is at best the
11th hour for making such a change in approach (perhaps even 5 minutes
to midnight?).
2) the 303 pattern isn't *that* hard to understand for newbies and maybe
even helps them grasp LOD. Making the difference between NIRs and IRs so
apparent, I have found to be (counter-intuitively) a big selling point
for LOD, when introducing new people to the paradigm. Let's not be too
harsh on 303 - it does make an important distinction very clear for new
adopters and, in my experience, it seems to be an approach new people
grok quite quickly and easily.
3) I see much to commend in what Ian suggests, in practical terms. If
the community is going to move in that direction what we need is a clear
roadmap. An alternative pattern (say, 200 OK plus Content-Location)
needs to be (*very* quickly) alighted upon and then used in practice. We
would have to reconcile ourselves to the 303 pattern and the
alternative, operating side-by-side, for some period of time (years?).
Only once there is some breadth of usage, should the community seek to
deprecate the use of 303s. If this is a pattern the community wishes to
change, we have to gradually evolve our way to something different. We
can't just leap.
Hope these thoughts help,
John.
On Sun, 2010-11-07 at 14:42 +, John Sheridan wrote:
One use-case that we have with the Linked Data work for UK Government,
is where we have a URI for a NIR at one (notionally more stable) domain
which 303s to an IR at a different (less stable, organisationally
orientated) domain.
Often the NIR URI is something like
http://{something}.data.gov.uk/id/something whereas the IR is on an
organisation's own website.
We do this because organisations in the public sector are unstable and
subject to continual change (creation, merger, abolition) whereas the
government as a whole is very stable.
To give an example, the Open Government Licence (for the NIR of the
licence) is http://reference.data.gov.uk/id/open-government-licence
which 303s to
http://www.nationalarchives.gov.uk/doc/open-government-licence/ (the IR
of the current licence text, currently published by The National
Archives, with HTML and RDF representations selected through conneg)
We are looking at a similar pattern for local authorities. Each Council
would have a NIR URI at (something like)
local.data.gov.uk/id/{local-council-identifier} which would 303 to IR
about that Council on the Council's own website.
Our thinking is that the {something}.data.gov.uk URI is more likely to
survive machinery of government changes, but the organisation
responsible for (say) the Open Government Licence is always going to
want to publish the IR about that on its own website, and should be
encouraged to do so.
The 303 pattern helps enable this pattern, which fits well in general
with some of the challenges on Linked Data in the public sector.
I would like to understand a little better how Ian's proposal maps to
this use case.
Grateful for comments,
John.
On Sun, 2010-11-07 at 12:11 +0100, Niklas Lindström wrote:
+1 indeed. Content-Location has definitely been overlooked. During
conneg, it is used to differ between a resource and its
representation(s), which are obviously different resources (well, not
necessarily the same). This distinction could certainly be enough to
remove the fundamental need for 303:ing on NIR:s (provided consensus
and some formal resolution).
(I pondered on a similar issue in
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2010Feb/0007.html,
regarding the identity of fragments. Perhaps that discussion would be
worth revisiting again in light of this?)
Best regards,
Niklas
On Fri, Nov 5, 2010 at 5:55 PM, Nathan nat...@webr3.org wrote:
Mike Kelly wrote:
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#page-14
snipped and fuller version inserted:
4. If the response has a Content-Location header field, and that URI
is not the same as the effective request URI, then the response
asserts that its payload is a representation of the resource
identified by the Content-Location URI. However, such an
assertion cannot be trusted unless it can be verified by other
means (not defined by HTTP).
If a client wants to make a statement about the specific document
then a response that includes a content-location is giving you the
information necessary to do that correctly. It's complemented and
further clarified in the entity
Re: isDefinedBy and isDescribedBy, Tale of two missing predicates
On 11/5/10 3:34 AM, Egon Willighagen wrote: Hi Kingsley, On Fri, Nov 5, 2010 at 1:58 AM, Kingsley Idehenkide...@openlinksw.com wrote: 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! So you have some examples where these two specifications are used? Egon Egon, Seen this mail kinda late, hence late response. Some examples: Links: 1. http://goo.gl/MG5iS -- shows a descriptor page, link/, and Link headers putting wdrs:describedBy to use 2. http://linkeddata.uriburner.com/describe/?url=http%3A%2F%2Fpurl.org%2Fgoodrelations%2Fv1p=12002 -- rdfs:isDefinedBy and its effects . -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Re: 200 OK with Content-Location might work
Hi John!
I understand your points. I also don't think that 303 is a poor
solution in any fundamental way. In fact, given the use-case you
described, having a stable URI which delegates to the current
location is perfectly fine, and in many cases preferable to the
alternative (demanding persistent, permanent hosting of all the data
in a dynamic organizational environment).
In our own work with gov data I can see our current central data
repo solution being turned into a PURL-like service for resources
like agency descriptions which should in time be put at more
appropriate, stable URL:s (combined with judicious owl:sameAs
assertions).
I just think that the demand on NIR:s w/o hashes to be directly
unavailable may be a hard hurdle to overcome when hosting data about
them (and as said elsewhere, can be an unnecessary strain on servers).
Milages certainly varies a lot, and simplifying the demand of 303:ing
from /concept to /concept.{dataformat} to a baseline where conneg
giving a Content-Location is formally enough can be very beneficial.
In fact, this makes the distinction of NIR vs. IR less technical (and
left to the descriptions of the resource to clarify), and just leaves
us with the importance of distinguishing between a resource and its
representations.
I basically think that the HTTP mechanics of 301, 302, 303 and 307
etc. are great tools for sustainable Linked Data deployment. But
having them dictate the fact that a URI represents a NIR or IR is
putting a lot of conceptual design directly into a day-to-day
protocol.. Of course, Content-Location doesn't remove the distinction
either, but it puts more emphasis on the resource vs representation
question, which holds for both resource kinds (AFAIK).
.. I usually steer away from discussions of the NIR vs. IR topic at
least publically (though I love to discuss it in person), since it
touches upon a very philosophical distinction which, taken to the
extreme, can be an eternal discussion (of epistemology, phenomenology
and whatnot). I hope that it is enough to say: if the resource does
not intrinsically have the mimetype X (represents itself, is the
record...), use HTTP mechanics (30x, or 200 + Content-Location) to
make it clear that the response body (having mimetype X) is not the
resource itself, but a representation thereof)...
Best regards,
Niklas
[For those wanting more things to ponder: consider the role and nature
of a packet, or the essence of a byte.. ;) ]
2010/11/7 John Sheridan johnlsheri...@yahoo.com:
Niklas,
In general I am supportive of your and Ian's thinking. 200 OK with
Content-Location might work.
However, three points from my perspective:
1) debating fundamental issues like this is very destabilising for those
of us looking to expand the LOD community and introduce new people and
organisations to Linked Data. To outsiders, it makes LOD seem like its
not ready for adoption and use - which is deadly. This is at best the
11th hour for making such a change in approach (perhaps even 5 minutes
to midnight?).
2) the 303 pattern isn't *that* hard to understand for newbies and maybe
even helps them grasp LOD. Making the difference between NIRs and IRs so
apparent, I have found to be (counter-intuitively) a big selling point
for LOD, when introducing new people to the paradigm. Let's not be too
harsh on 303 - it does make an important distinction very clear for new
adopters and, in my experience, it seems to be an approach new people
grok quite quickly and easily.
3) I see much to commend in what Ian suggests, in practical terms. If
the community is going to move in that direction what we need is a clear
roadmap. An alternative pattern (say, 200 OK plus Content-Location)
needs to be (*very* quickly) alighted upon and then used in practice. We
would have to reconcile ourselves to the 303 pattern and the
alternative, operating side-by-side, for some period of time (years?).
Only once there is some breadth of usage, should the community seek to
deprecate the use of 303s. If this is a pattern the community wishes to
change, we have to gradually evolve our way to something different. We
can't just leap.
Hope these thoughts help,
John.
On Sun, 2010-11-07 at 14:42 +, John Sheridan wrote:
One use-case that we have with the Linked Data work for UK Government,
is where we have a URI for a NIR at one (notionally more stable) domain
which 303s to an IR at a different (less stable, organisationally
orientated) domain.
Often the NIR URI is something like
http://{something}.data.gov.uk/id/something whereas the IR is on an
organisation's own website.
We do this because organisations in the public sector are unstable and
subject to continual change (creation, merger, abolition) whereas the
government as a whole is very stable.
To give an example, the Open Government Licence (for the NIR of the
licence) is http://reference.data.gov.uk/id/open-government-licence
which 303s to
Re: 200 OK with Content-Location might work
Hi John
Your points are good ones and some care should certainly be taken in how a
possible 200-with-content-location option should be presented to the 'outside
world'.
1) the public-lod forum is mostly aimed at practitioners, so hopefully not too
many new LODers will have been alarmed by the recent discussion. Maybe it's 5
to midnight, but better now than 5 after midnight!
2) I think you're right that it's not that hard to understand the 303 stuff,
but it *is* a pain to implement in a web server and I think that's an obstacle
to wider adoption of linked data.
3) Most on this list seem to be in agreement that the new option should be in
addition to 303 as a way of doing LOD with slash URIs and the different
approach doesn't make a great deal of difference to most LOD consuming
applications. I agree that we should try to make a quick decision on whether
to start implementing this approach. In due course it would probably be worth
reconsidering guidance notes like http://data.gov.uk/resources/uris. The
pattern of id/doc URI pairs is not needed in the 200 approach, but it may be
best to stick to recommending the /id/ pattern for data.gov.uk URIs for the
sake of consistency and continuity - not sure about that, needs some thought.
Cheers
Bill
On 7 Nov 2010, at 16:07, John Sheridan wrote:
Niklas,
In general I am supportive of your and Ian's thinking. 200 OK with
Content-Location might work.
However, three points from my perspective:
1) debating fundamental issues like this is very destabilising for those
of us looking to expand the LOD community and introduce new people and
organisations to Linked Data. To outsiders, it makes LOD seem like its
not ready for adoption and use - which is deadly. This is at best the
11th hour for making such a change in approach (perhaps even 5 minutes
to midnight?).
2) the 303 pattern isn't *that* hard to understand for newbies and maybe
even helps them grasp LOD. Making the difference between NIRs and IRs so
apparent, I have found to be (counter-intuitively) a big selling point
for LOD, when introducing new people to the paradigm. Let's not be too
harsh on 303 - it does make an important distinction very clear for new
adopters and, in my experience, it seems to be an approach new people
grok quite quickly and easily.
3) I see much to commend in what Ian suggests, in practical terms. If
the community is going to move in that direction what we need is a clear
roadmap. An alternative pattern (say, 200 OK plus Content-Location)
needs to be (*very* quickly) alighted upon and then used in practice. We
would have to reconcile ourselves to the 303 pattern and the
alternative, operating side-by-side, for some period of time (years?).
Only once there is some breadth of usage, should the community seek to
deprecate the use of 303s. If this is a pattern the community wishes to
change, we have to gradually evolve our way to something different. We
can't just leap.
Hope these thoughts help,
John.
On Sun, 2010-11-07 at 14:42 +, John Sheridan wrote:
One use-case that we have with the Linked Data work for UK Government,
is where we have a URI for a NIR at one (notionally more stable) domain
which 303s to an IR at a different (less stable, organisationally
orientated) domain.
Often the NIR URI is something like
http://{something}.data.gov.uk/id/something whereas the IR is on an
organisation's own website.
We do this because organisations in the public sector are unstable and
subject to continual change (creation, merger, abolition) whereas the
government as a whole is very stable.
To give an example, the Open Government Licence (for the NIR of the
licence) is http://reference.data.gov.uk/id/open-government-licence
which 303s to
http://www.nationalarchives.gov.uk/doc/open-government-licence/ (the IR
of the current licence text, currently published by The National
Archives, with HTML and RDF representations selected through conneg)
We are looking at a similar pattern for local authorities. Each Council
would have a NIR URI at (something like)
local.data.gov.uk/id/{local-council-identifier} which would 303 to IR
about that Council on the Council's own website.
Our thinking is that the {something}.data.gov.uk URI is more likely to
survive machinery of government changes, but the organisation
responsible for (say) the Open Government Licence is always going to
want to publish the IR about that on its own website, and should be
encouraged to do so.
The 303 pattern helps enable this pattern, which fits well in general
with some of the challenges on Linked Data in the public sector.
I would like to understand a little better how Ian's proposal maps to
this use case.
Grateful for comments,
John.
On Sun, 2010-11-07 at 12:11 +0100, Niklas Lindström wrote:
+1 indeed. Content-Location has definitely been overlooked. During
conneg, it is used to differ between a resource and its
Re: isDefinedBy and isDescribedBy, Tale of two missing predicates
Hi Kingsley, On Sun, Nov 7, 2010 at 4:50 PM, Kingsley Idehen kide...@openlinksw.com wrote: Seen this mail kinda late, hence late response. Some examples: No worries! Links: 1. http://goo.gl/MG5iS -- shows a descriptor page, link/, and Link headers putting wdrs:describedBy to use 2. http://linkeddata.uriburner.com/describe/?url=http%3A%2F%2Fpurl.org%2Fgoodrelations%2Fv1p=12002 -- rdfs:isDefinedBy and its effects . Thanks! Very much appreciated! Egon -- Dr E.L. Willighagen Postdoctoral Research Associate University of Cambridge Homepage: http://egonw.github.com/ LinkedIn: http://se.linkedin.com/in/egonw Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers
Re: 200 OK with Content-Location might work
On 11/7/10 10:07 AM, John Sheridan wrote:
Niklas,
In general I am supportive of your and Ian's thinking. 200 OK with
Content-Location might work.
However, three points from my perspective:
1) debating fundamental issues like this is very destabilising for those
of us looking to expand the LOD community and introduce new people and
organisations to Linked Data. To outsiders, it makes LOD seem like its
not ready for adoption and use - which is deadly. This is at best the
11th hour for making such a change in approach (perhaps even 5 minutes
to midnight?).
+1
We must put concept (and value prop. demonstration) before mechanics.
This mailing list isn't private, it has google-juice, and its an early
point of call re. Linked Data.
2) the 303 pattern isn't *that* hard to understand for newbies and maybe
even helps them grasp LOD.
And when the dust settles, it will remain. Ian's efforts will have the
net effect of a new option, no more no less. Just an option.
Loose coupling (non authoritative) resource descriptors (information
resources) are going to be important forever.
Pubby and Virtuoso have always demonstrated the above. In the beginning
Pubby (Linked Data Document middleware) was in Berlin and the DBpedia
Quad Store in Burlington, MA. Today, via Virtuoso we still have all
sorts of options re. location of the Linked Data Docs relative to the
actual DBpedia Quad Store. This kind of flexibility is vital to Linked
Data in general.
Making the difference between NIRs and IRs so
apparent, I have found to be (counter-intuitively) a big selling point
for LOD, when introducing new people to the paradigm. Let's not be too
harsh on 303 - it does make an important distinction very clear for new
adopters and, in my experience, it seems to be an approach new people
grok quite quickly and easily.
The Descriptor Document URL and Subject Name dichotomy is intuitive. It
does help new users and anyone else that's concept comprehension
oriented re. Linked Data.
3) I see much to commend in what Ian suggests, in practical terms. If
the community is going to move in that direction what we need is a clear
roadmap. An alternative pattern (say, 200 OK plus Content-Location)
needs to be (*very* quickly) alighted upon and then used in practice. We
would have to reconcile ourselves to the 303 pattern and the
alternative, operating side-by-side, for some period of time (years?).
This is just an option, it can never be more than an option.
Only once there is some breadth of usage, should the community seek to
deprecate the use of 303s.
I don't think 303 indirection can be depreciated. We just have another
option that full leverages the self-describing nature of RDF resources.
The mechanism for disambiguating Entity (Non Information Resource) Name
and Descriptor (Information Resource) Address is adjudicated by the data
itself.
If this is a pattern the community wishes to
change, we have to gradually evolve our way to something different. We
can't just leap.
An optional evolutionary path. This is something platforms you handle
without distraction to users.
Hope these thoughts help,
Very much so :-)
Kingsley
John.
On Sun, 2010-11-07 at 14:42 +, John Sheridan wrote:
One use-case that we have with the Linked Data work for UK Government,
is where we have a URI for a NIR at one (notionally more stable) domain
which 303s to an IR at a different (less stable, organisationally
orientated) domain.
Often the NIR URI is something like
http://{something}.data.gov.uk/id/something whereas the IR is on an
organisation's own website.
We do this because organisations in the public sector are unstable and
subject to continual change (creation, merger, abolition) whereas the
government as a whole is very stable.
To give an example, the Open Government Licence (for the NIR of the
licence) is http://reference.data.gov.uk/id/open-government-licence
which 303s to
http://www.nationalarchives.gov.uk/doc/open-government-licence/ (the IR
of the current licence text, currently published by The National
Archives, with HTML and RDF representations selected through conneg)
We are looking at a similar pattern for local authorities. Each Council
would have a NIR URI at (something like)
local.data.gov.uk/id/{local-council-identifier} which would 303 to IR
about that Council on the Council's own website.
Our thinking is that the {something}.data.gov.uk URI is more likely to
survive machinery of government changes, but the organisation
responsible for (say) the Open Government Licence is always going to
want to publish the IR about that on its own website, and should be
encouraged to do so.
The 303 pattern helps enable this pattern, which fits well in general
with some of the challenges on Linked Data in the public sector.
I would like to understand a little better how Ian's proposal maps to
this use case.
Grateful for comments,
John.
On Sun, 2010-11-07 at 12:11 +0100, Niklas Lindström wrote:
+1
Re: 200 OK with Content-Location might work
On 11/7/10 11:17 AM, Bill Roberts wrote:
Hi John
Your points are good ones and some care should certainly be taken in how a
possible 200-with-content-location option should be presented to the 'outside
world'.
1) the public-lod forum is mostly aimed at practitioners, so hopefully not too
many new LODers will have been alarmed by the recent discussion. Maybe it's 5
to midnight, but better now than 5 after midnight!
2) I think you're right that it's not that hard to understand the 303 stuff,
but it *is* a pain to implement in a web server and I think that's an obstacle
to wider adoption of linked data.
Implementation cannot be the reason for making these changes. Linked
Data isn't about the limitations of Apache or any other server platform.
The core problem is that we have an ambiguity that needs to be resolved.
The current 303 indirection heuristic boils down to a human agreement
re., when a URI is a Name or Address. Leveraging triples in an RDF
resource basically illustrates the value of self-describing structured
data, a critical component of Linked Data value prop.
3) Most on this list seem to be in agreement that the new option should be in
addition to 303 as a way of doing LOD with slash URIs and the different
approach doesn't make a great deal of difference to most LOD consuming
applications.
Yes.
I agree that we should try to make a quick decision on whether to start
implementing this approach.
Support this approach as an option via implementation across current
handful of platforms, why not, but we still need to invest energy in:
1. emphasizing this is an option
2. non disruptive addition to existing Linked Data products
3. not making this a distraction .
In due course it would probably be worth reconsidering guidance notes like
http://data.gov.uk/resources/uris. The pattern of id/doc URI pairs is not
needed in the 200 approach, but it may be best to stick to recommending the
/id/ pattern for data.gov.uk URIs for the sake of consistency and continuity -
not sure about that, needs some thought.
Wouldn't suggest touching that at all. The URIs are in place and fully
functional.
Kingsley
Cheers
Bill
On 7 Nov 2010, at 16:07, John Sheridan wrote:
Niklas,
In general I am supportive of your and Ian's thinking. 200 OK with
Content-Location might work.
However, three points from my perspective:
1) debating fundamental issues like this is very destabilising for those
of us looking to expand the LOD community and introduce new people and
organisations to Linked Data. To outsiders, it makes LOD seem like its
not ready for adoption and use - which is deadly. This is at best the
11th hour for making such a change in approach (perhaps even 5 minutes
to midnight?).
2) the 303 pattern isn't *that* hard to understand for newbies and maybe
even helps them grasp LOD. Making the difference between NIRs and IRs so
apparent, I have found to be (counter-intuitively) a big selling point
for LOD, when introducing new people to the paradigm. Let's not be too
harsh on 303 - it does make an important distinction very clear for new
adopters and, in my experience, it seems to be an approach new people
grok quite quickly and easily.
3) I see much to commend in what Ian suggests, in practical terms. If
the community is going to move in that direction what we need is a clear
roadmap. An alternative pattern (say, 200 OK plus Content-Location)
needs to be (*very* quickly) alighted upon and then used in practice. We
would have to reconcile ourselves to the 303 pattern and the
alternative, operating side-by-side, for some period of time (years?).
Only once there is some breadth of usage, should the community seek to
deprecate the use of 303s. If this is a pattern the community wishes to
change, we have to gradually evolve our way to something different. We
can't just leap.
Hope these thoughts help,
John.
On Sun, 2010-11-07 at 14:42 +, John Sheridan wrote:
One use-case that we have with the Linked Data work for UK Government,
is where we have a URI for a NIR at one (notionally more stable) domain
which 303s to an IR at a different (less stable, organisationally
orientated) domain.
Often the NIR URI is something like
http://{something}.data.gov.uk/id/something whereas the IR is on an
organisation's own website.
We do this because organisations in the public sector are unstable and
subject to continual change (creation, merger, abolition) whereas the
government as a whole is very stable.
To give an example, the Open Government Licence (for the NIR of the
licence) is http://reference.data.gov.uk/id/open-government-licence
which 303s to
http://www.nationalarchives.gov.uk/doc/open-government-licence/ (the IR
of the current licence text, currently published by The National
Archives, with HTML and RDF representations selected through conneg)
We are looking at a similar pattern for local authorities. Each Council
would have a NIR URI at (something like)
Re: 200 OK with Content-Location might work
I share John's unease here. And I remain uneasy about the 200 C-L solution.
I know I sound like a fundamentalist in a discussion where we're trying
to find a practical, workable solution, but is a description of a toucan
a representation of a toucan? IMO, it's not. Sure, one can imagine an
HTTP response returning a very rich data stream that conveys the entire
experience of having a toucan on your desk - but the toucan ain't
actually there.
I've been toying with the idea of including a substitution rule in a 200
header.
Following the practice of using /id/ for NIRs and /doc/ for their
descriptions, suppose a GET on http://example.com/id/toucan returned:
200 OK
Apply-URI-substitution: s/id/doc/
Content-type: text/html
Blah blah...
In just one trip, user agents would then be able to interpret this as a
document whose URI can be derived by performing the substitution,
knowing that the returned data describes the thing identified by the
original URI.
This approach, and C-L approach, both require client side implementation
of course.
My worry is that any 200-based solution is going to be poorly
implemented in the real world by both browsers and LOD publishers (Talis
excepted of course!) so that IRs and NIRs will be indistinguishable 'in
the wild'.
303 works already, and that is still the one that feels right to me. I'm
happy that the discussion here is centred on adding a new method cf.
replacing 303, especially as the HTTP-Bis group seems to have made its
use for LOD and explicit part of the definition.
Phil.
On 07/11/2010 15:07, John Sheridan wrote:
Niklas,
In general I am supportive of your and Ian's thinking. 200 OK with
Content-Location might work.
However, three points from my perspective:
1) debating fundamental issues like this is very destabilising for those
of us looking to expand the LOD community and introduce new people and
organisations to Linked Data. To outsiders, it makes LOD seem like its
not ready for adoption and use - which is deadly. This is at best the
11th hour for making such a change in approach (perhaps even 5 minutes
to midnight?).
2) the 303 pattern isn't *that* hard to understand for newbies and maybe
even helps them grasp LOD. Making the difference between NIRs and IRs so
apparent, I have found to be (counter-intuitively) a big selling point
for LOD, when introducing new people to the paradigm. Let's not be too
harsh on 303 - it does make an important distinction very clear for new
adopters and, in my experience, it seems to be an approach new people
grok quite quickly and easily.
3) I see much to commend in what Ian suggests, in practical terms. If
the community is going to move in that direction what we need is a clear
roadmap. An alternative pattern (say, 200 OK plus Content-Location)
needs to be (*very* quickly) alighted upon and then used in practice. We
would have to reconcile ourselves to the 303 pattern and the
alternative, operating side-by-side, for some period of time (years?).
Only once there is some breadth of usage, should the community seek to
deprecate the use of 303s. If this is a pattern the community wishes to
change, we have to gradually evolve our way to something different. We
can't just leap.
Hope these thoughts help,
John.
On Sun, 2010-11-07 at 14:42 +, John Sheridan wrote:
One use-case that we have with the Linked Data work for UK Government,
is where we have a URI for a NIR at one (notionally more stable) domain
which 303s to an IR at a different (less stable, organisationally
orientated) domain.
Often the NIR URI is something like
http://{something}.data.gov.uk/id/something whereas the IR is on an
organisation's own website.
We do this because organisations in the public sector are unstable and
subject to continual change (creation, merger, abolition) whereas the
government as a whole is very stable.
To give an example, the Open Government Licence (for the NIR of the
licence) is http://reference.data.gov.uk/id/open-government-licence
which 303s to
http://www.nationalarchives.gov.uk/doc/open-government-licence/ (the IR
of the current licence text, currently published by The National
Archives, with HTML and RDF representations selected through conneg)
We are looking at a similar pattern for local authorities. Each Council
would have a NIR URI at (something like)
local.data.gov.uk/id/{local-council-identifier} which would 303 to IR
about that Council on the Council's own website.
Our thinking is that the {something}.data.gov.uk URI is more likely to
survive machinery of government changes, but the organisation
responsible for (say) the Open Government Licence is always going to
want to publish the IR about that on its own website, and should be
encouraged to do so.
The 303 pattern helps enable this pattern, which fits well in general
with some of the challenges on Linked Data in the public sector.
I would like to understand a little better how Ian's proposal maps to
this use case.
Grateful for
Re: 200 OK with Content-Location might work
On Sun, Nov 7, 2010 at 7:35 PM, Phil Archer ph...@w3.org wrote: I share John's unease here. And I remain uneasy about the 200 C-L solution. I know I sound like a fundamentalist in a discussion where we're trying to find a practical, workable solution, but is a description of a toucan a representation of a toucan? IMO, it's not. Sure, one can imagine an HTTP response returning a very rich data stream that conveys the entire experience of having a toucan on your desk - but the toucan ain't actually there. The content-location header says that the entity being sent in the response is not a representation of the resource. I don't want to get into a heavy what is a representation really debate because those have been done to minute detail over on the TAG list for many years. Suffice to say that http://www.google.com/ has a representation that is not the entire experience of the google website get that URI denotes the google website for the majoriity of people. I've been toying with the idea of including a substitution rule in a 200 header. I'd prefer not to invent anything new, e.g. new headers or status codes. I'm just looking to simplify an existing set of patterns. My worry is that any 200-based solution is going to be poorly implemented in the real world by both browsers and LOD publishers (Talis excepted of course!) so that IRs and NIRs will be indistinguishable 'in the wild'. My proposal keeps the two separate with distinct URIs. With clear guides, education and testing tools we can encourage people to do the right thing, just like we currently do with any standard. However, philosophically I wonder whether there are any practical consequences of them being indistinguishable. When i read my email in gmail it is hard to separate the email from the webpage allowing me to read the email yet it still works. 303 works already, and that is still the one that feels right to me. I'm happy that the discussion here is centred on adding a new method cf. replacing 303, especially as the HTTP-Bis group seems to have made its use for LOD and explicit part of the definition. It would still be available. My proposal is to provide a streamlined alternative, one that is more in line with what millions of webmasters are doing already. Ian
Re: [foaf-dev] EON - event of note
On Sun, 7 Nov 2010 13:26:15 +0100 Michael Schneider schn...@fzi.de wrote: For your information, the term EON is also used as the acronym of the International Workshop on Evaluation of Ontology-based Tools, an (almost-) yearly event that exists since 2002. See [1] for the proceedings of the first EON workshop. It would probably not be advisable to reuse the acronym for something else in the Semantic Web context. I'm aware of it, but thought that confusion between them would likely be minimal. What do other people think? If others think confusion is likely, I have a backup name: the Event Representation Argot. :-) -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: [foaf-dev] EON - event of note
Is there some reason not to use LODE? http://linkedevents.org/ontology/ -- Rob Sanderson On Sun, Nov 7, 2010 at 2:21 PM, Toby Inkster t...@g5n.co.uk wrote: On Sun, 7 Nov 2010 13:26:15 +0100 Michael Schneider schn...@fzi.de wrote: For your information, the term EON is also used as the acronym of the International Workshop on Evaluation of Ontology-based Tools, an (almost-) yearly event that exists since 2002. See [1] for the proceedings of the first EON workshop. It would probably not be advisable to reuse the acronym for something else in the Semantic Web context. I'm aware of it, but thought that confusion between them would likely be minimal. What do other people think? If others think confusion is likely, I have a backup name: the Event Representation Argot. :-) -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: 200 OK with Content-Location might work
On 11/7/10 2:35 PM, Phil Archer wrote: I share John's unease here. And I remain uneasy about the 200 C-L solution. I know I sound like a fundamentalist in a discussion where we're trying to find a practical, workable solution, but is a description of a toucan a representation of a toucan? Put differently, a Toucan has a structured description, expressed using triples, contained in an RDF resource (that has an Address), that's transmissible in a variety of formats (representation) to user agents over HTTP. The discernible attributes of the Entity (Thing) named: Toucan, are expressed in a digital representation of its description, by an observer. You have 3 vital components (trinity) that constitute a structured description: 1. Toucan -- the real world object and description subject 2. URI -- identifier that has Toucan as referent 3. Resource -- the container of triples used to express description of the subject (Tucan). IMO, it's not. Sure, one can imagine an HTTP response returning a very rich data stream that conveys the entire experience of having a toucan on your desk - but the toucan ain't actually there. Correct. It's just a referent of the URI. The URI may be a Name or an Address. The data -- fully self-describing -- determines the subject of the description by Name (via triples). Thus, overrides the ambiguities of HTTP as experienced by user agents. If you break the trinity outlined above, and you overload on the term Resource, all of this comes through as absolute gobbledygook to people who don't speak or comprehend fluent Resource Moniker Overloading. I've been toying with the idea of including a substitution rule in a 200 header. Following the practice of using /id/ for NIRs and /doc/ for their descriptions, suppose a GET on http://example.com/id/toucan returned: 200 OK Apply-URI-substitution: s/id/doc/ Content-type: text/html Blah blah... Not required, we just have to make up our minds about when we stop overloading on Resource. It's taken close to 12 years to accept that RDF/XML is gobbledygook outside the Semantic Web community. RDFa is sorta accepted reluctantly re. normative format, but it still isn't deemed normative. I have no idea how long its going to take for Resource overloading to dissipate, but I do know that EAV + Resolvable Identifiers will take shape elsewhere, and Linked Data (the concept) will be understood without today's syntax + model conflation alongside Resource terminology overload distractions. In just one trip, user agents would then be able to interpret this as a document whose URI can be derived by performing the substitution, knowing that the returned data describes the thing identified by the original URI. Linked Data aware user agents should be able to use 'Content-Location' header values to determine if they are dealing with a Name or an Address, by processing the EAV graph exposed by a resource (which includes RDF resources). Nothing stops resources exposed by 'Content-Location' from being a container of EAV model data expressed using: OData+Atom, OData+JSON, GData, or any other markup/syntax. User Agents should negotiate data representation formats and then process the data using underlying data model semantics. Don't want to beat a dead horse, but RDF != Linked Data (the concept). TimBL posted a note about how to effectively publish (actually inject) Linked Data into the World Wide Web. That doesn't in anyway confine the concept of Linked Data to RDF or even HTTP. This approach, and C-L approach, both require client side implementation of course. My worry is that any 200-based solution is going to be poorly implemented in the real world by both browsers and LOD publishers (Talis excepted of course!) so that IRs and NIRs will be indistinguishable 'in the wild'. 303 works already, and that is still the one that feels right to me. I'm happy that the discussion here is centred on adding a new method cf. replacing 303, especially as the HTTP-Bis group seems to have made its use for LOD and explicit part of the definition. This is not about replacing 303's re. slash terminated HTTP URIs used as Entity Names. It's simply another option for handling Name / Address disambiguation for this type of URI via the data itself. Links: 1. http://www.slideshare.net/kidehen/understanding-linked-data-via-eav-model-based-structured-descriptions -- demystification of Linked Data using EAV model HTTP URIs 2. http://www.slideshare.net/kidehen/iss-1 -- covers Syntax and Conceptual Schema (model) separation 3. http://ontolog.cim3.net/forum/ontolog-forum/2010-09/msg00318.html -- post from ontolog forum by John F. Sowa that explains Entities and other related matters 4. http://www.w3.org/People/Connolly/9703-web-apps-essay.html -- 1997 article by DanC, that also sheds valuable insight into HTTP roots (Objective-C Distributed Objects) and by implication the superficiality of the Resource
Re: [foaf-dev] EON - event of note
On Sun, 7 Nov 2010 14:50:58 -0700 Robert Sanderson azarot...@gmail.com wrote: Is there some reason not to use LODE? http://linkedevents.org/ontology/ A few, though they could possibly be addressed by a revision of LODE: 1. lode:Event appears to be restricted to events which have already happened. One of the main use cases for EON is to describe events which are planned. 2. Its time properties use OWL Time which is overly complicated for the lightweight FOAF-style vocabulary I'm aiming for, suitable for easy embedding in web pages. 3. It's missing certain properties that seem to be useful to cover the kind events that are advertised/mentioned on the Web - cost, booking links, etc. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: 200 OK with Content-Location might work
How to present to the outside world? In fact, perhaps why are we doing this? People *are* doing conneg and returning 200 rdf right now, and many of us expect that this will continue and even increase, despite any instructions/recommendations to the contrary from the LOD community. So it is incumbent on us as a community to respond to this situation. Suggesting Best Practice for a 200 approach this does not undermine 303 or hash, and we continue to recommend this, especially for sites like data.gov.uk. But a clear statement about 200 helps to improve the situation by offering a common approach and preserving the distinction between NIR and IR. Clearly we are a stable community and LOD is ready for adoption if we can respond to such changes in the envirnment without breaking the existing world, while embracing new users ;-) Best Hugh
Re: isDefinedBy and isDescribedBy, Tale of two missing predicates
I was wondering if an example might help me understand this better. I have currently been linking between entities and the RDF that describes them using foaf:topic and foaf:page If I understand this correctly, I would continue to use foaf:topic to point from the RDF page to the entities it describes, but use wdrs:describedBy to link from the entity to the RDF that describe it. For example, for this page http://ocs.taxonconcept.org/ocs/f522444a-2dd9-400e-be59-47213ef38cb9.rdf I should replace the entries of: foaf:page rdf:resource= http://ocs.taxonconcept.org/ocs/f522444a-2dd9-400e-be59-47213ef38cb9.rdf/ with wdrs:describedBy rdf:resource= http://ocs.taxonconcept.org/ocs/f522444a-2dd9-400e-be59-47213ef38cb9.rdf/ Also, is there a reason why there is not inverse predicate like wdrs:describes? Thanks! - Pete On Sun, Nov 7, 2010 at 9:50 AM, Kingsley Idehen kide...@openlinksw.comwrote: On 11/5/10 3:34 AM, Egon Willighagen wrote: Hi Kingsley, On Fri, Nov 5, 2010 at 1:58 AM, Kingsley Idehen kide...@openlinksw.com kide...@openlinksw.com wrote: 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! So you have some examples where these two specifications are used? Egon Egon, Seen this mail kinda late, hence late response. Some examples: Links: 1. http://goo.gl/MG5iS -- shows a descriptor page, link/, and Link headers putting wdrs:describedBy to use 2. http://linkeddata.uriburner.com/describe/?url=http%3A%2F%2Fpurl.org%2Fgoodrelations%2Fv1p=12002-- rdfs:isDefinedBy and its effects . -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen -- --- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base http://www.taxonconcept.org/ / GeoSpecies Knowledge Base http://lod.geospecies.org/ About the GeoSpecies Knowledge Base http://about.geospecies.org/
Re: More browsers for ISWC 2010 data?
Thank all for providing valuable inputs. Now the list [1] is extended with * Bibliographic Data (Note that all authors are linked to DBLP) * ISWC Explorer by fluid Operations, based on Information Workbench * More Browsers: Disco, Marbles, SIOC RDF Browser, Zitgist, Explorator [1] http://www.w3.org/2001/sw/wiki/ISWC_2010_Data_and_Demos Jie On Sun, Nov 7, 2010 at 02:06, Jie Bao bao...@gmail.com wrote: Hi all, I added a few known data browsers that can work with ISWC 2010 data [1]. If you know other live demos that can browse/visualize the dataset, please expand the list, or let me know. [1] http://www.w3.org/2001/sw/wiki/ISWC_2010_Data_and_Demos#General-purpose_browsers_that_can_work_with_ISWC_data Cheers! Jie - Jie Bao Tetherless World Constellation Rensselaer Polytechnic Institute bao...@cs.rpi.edu http://www.cs.rpi.edu/~baojie
Re: 200 OK with Content-Location might work
Hi Phil! Phil Archer wrote: I know I sound like a fundamentalist in a discussion where we're trying to find a practical, workable solution, but is a description of a toucan a representation of a toucan? IMO, it's not. Sure, one can imagine an HTTP response returning a very rich data stream that conveys the entire experience of having a toucan on your desk - but the toucan ain't actually there. Since this distinction is, and has been for many years, debatable, why not be pragmatic and leave this choice to the users themselves? If someone thinks that a web page consisting of a picture and a textual description is an adequate represenation of a Toucan, let them return one over HTTP (as long as they are aware that the web page itself is a different resource yada yada...). People expecting the Toucan to fly down the wire and appear at their desk might me disappointed but most users will probably be happy with the low-fidelity version. Tore Eriksson ___ Tore Eriksson [tore.eriksson at po.rd.taisho.co.jp]
Re: [foaf-dev] EON - event of note
Is there some reason not to use LODE? http://linkedevents.org/ontology/ Thanks for this suggestion Rob ;-) Raphaël -- Raphaël Troncy EURECOM, Multimedia Communications Department 2229, route des Crêtes, 06560 Sophia Antipolis, France. e-mail: raphael.tro...@eurecom.fr raphael.tro...@gmail.com Tel: +33 (0)4 - 9300 8242 Fax: +33 (0)4 - 9000 8200 Web: http://www.eurecom.fr/~troncy/
Linked Data gathering today
Hello, While the Consuming Linked Data workshop is running, we want to invite the participants and everybody else who is interested in Linked Data to a Linked Data gathering in the evening. We will gather at The Bund Brewery, 11 Hankou Lu, 8pm. If you want to eat before, there are a lot restaurants in the area where the brewery is. See you tonight, Olaf
Re: Is 303 really necessary? (Multiple things described in a single document)
Hi Ian, On Fri, 2010-11-05 at 10:59 +, Ian Davis wrote: I have a question about http://thing-described-by.org/ - how does it work when my description document describes multiple things? Really, any RDF document that references more than one resource as a subject or object can be considered to be providing a description of all those resources. It sounds like you are getting into the distinction between what I've been calling core assertions and ancillary assertions: http://dbooth.org/2007/uri-decl/#uri-decl http://dbooth.org/2007/uri-decl/#ancillary In a nutshell, the core assertions of a URI are those that the URI owner has authoritatively provided in its URI declaration, that all statement authors using that URI *should* accept (or else they should not use the URI): http://dbooth.org/2009/lifecycle/#event2 [[ Statement author responsibility 3: Use of a URI implies agreement with the core assertions of its URI declaration. ]] For example, the assertions about http://iandavis.com/2010/303/toucan that you provided in http://iandavis.com/2010/303/toucan.rdf are *core* assertions with respect to http://iandavis.com/2010/303/toucan , because you own that URI. Thus, anyone using that URI to make RDF statements about your toucan *should* accept your assertions. (Otherwise they may be talking about a different toucan!) However, if *I* make statements using your toucan URI http://iandavis.com/2010/303/toucan , my assertions are *ancillary* assertions with respect to (WRT) that URI: other RDF statement authors using your toucan URI are free to use or ignore my statements, because they are not authoritative WRT that URI. So, even though your URI declaration at http://iandavis.com/2010/303/toucan.rdf may make assertions about many subjects, those assertions only act as *core* assertions for http://iandavis.com/2010/303/toucan . They act as *ancillary* assertions for other URIs. Note that the exact same assertion can be a core assertion WRT one URI, but an ancillary assertion WRT another URI. This is normal, because assertions that are authoritative WRT one URI declaration may be non-authoritative WRT another URI. The reason for this distinction between core and ancillary assertions is to ensure that when different people talk about http://iandavis.com/2010/303/toucan we can know that they are all talking about the *same* toucan (at least within the limits of the ambiguity in that toucan's definition). If different statement authors http://dbooth.org/2009/lifecycle/#statementAuthor used different URI declarations for your toucan URI then they would run the risk of talking about *different* toucans. (Actually, they still run the risk of talking about different toucans, as illustrated by graphs A and C here: http://dbooth.org/2010/ambiguity/paper.html#inconsistent-merge but the risk is reduced.) I'll address your other questions separately, so that this email message doesn't get even longer. -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Re: Is 303 really necessary? (dealing with ambiguity)
On Fri, 2010-11-05 at 10:59 +, Ian Davis wrote: On Thu, Nov 4, 2010 at 10:10 PM, David Booth da...@dbooth.org wrote: 2. only one description can be linked from the toucan's URI True, but that's far better than zero, if you only have the toucan URI and it returns 404! It could return 204. I don't understand where you're going with that. How would a 204 permit more than one description to be linked from the toucan's URI? 3. the user enters one URI into their browser and ends up at a different one, causing confusion when they want to reuse the URI of the toucan. Often they use the document URI by mistake. Yes, that's a problem. The trade-off is ambiguity. I don't think so. The ambiguity is not present because the data explicitly distinguishes the two URIs (and content-location header does too). I would say that the ambiguity *has* been created, but your heuristic (of looking at the provenance of whether the information came from the HTTP response code permits that ambiguity to be resolved. There are millions of people that use URIs to identify billions of web pages, and the vast majority have never heard of RDF. If your toucan URI returns a 200 response just like billions of other URIs then it *does* identify a web page, even if you are also using that URI in some RDF document to identify a toucan -- a document that would just be gobbledygook to most of the world. And others may well make statements about that web page. For example, someone crawling the web may make a statement saying that http://iandavis.com/2010/303/toucan returned 1027 bytes in response to a GET request. They may not say it in RDF -- they might say it in XML or any other language. (Indeed, they may know nothing about RDF.) But they still use http://iandavis.com/2010/303/toucan to identify the web page, and no amount of RDF can change that fact. Furthermore, their statements may eventually be translated to RDF -- perhaps by someone else -- and merged with other assertions that use http://iandavis.com/2010/303/toucan to refer to the toucan. So I don't think it is reasonable or realistic to think that we can *avoid* creating an ambiguity by returning additional RDF statements with the 200 response. Rather, the heuristic that you propose is a way for applications to *deal* with that ambiguity by tracking the provenance of the information: if one set of assertions was derived from an HTTP 200 response code, and another set of assertions was derived from an RDF document that you trust, then ignore the assertions that were derived from the HTTP 200 response code. 7. it mixes layers of responsibility - there is information a user cannot know without making a network request and inspecting the metadata about the response to that request. When the web server ceases to exist then that information is lost. I don't buy this argument. While I agree that explicit statements such as Utoucan :isDescribedBy Upage . is helpful and should be provided, that does *not* mean that links are not *also* useful. Just because links do not *always* work does not mean that they are useless. But you agree that under the current scheme, some things are knowable only by making a network request. It's not enough to have just the RDF description document? Sorry, I may have been unclear. I *do* think that if the client app already has enough RDF data about Utoucan then the client app should not waste a network access dereferencing Utoucan. However, I think the URI owner of Utoucan *should* still make Utoucan dereferenceable (either directly or indirectly) to RDF data, because this may be useful to the client app for cases when it either doesn't have sufficient RDF data about Utoucan or if it wishes to verify that it has the correct or current RDF data about Utoucan. -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Re: Is 303 really necessary? (dealing with ambiguity)
Hi David, David Booth wrote: There are millions of people that use URIs to identify billions of web pages, and the vast majority have never heard of RDF. Most of these millions haven't heard of, nor care about, the HTML contained in the web page either. Thus, saying that millions of people use the URI to denote the underlying HTML document seems like a stretch of imagination. If your toucan URI returns a 200 response just like billions of other URIs then it *does* identify a web page, even if you are also using that URI in some RDF document to identify a toucan -- a document that would just be gobbledygook to most of the world. Reading W3 mailing lists have made me wary of words like identify. You can get a home page by doing a HTTP GET on the URI, but the relationship to the original URI is not well defined. Why can't we just leave it like that. Use RDF for describing resources in detail. And others may well make statements about that web page. For example, someone crawling the web may make a statement saying that http://iandavis.com/2010/303/toucan returned 1027 bytes in response to a GET request. They may not say it in RDF -- they might say it in XML or any other language. As long as they they are aware that they are talking about a specific representation of this resource I can't see any problem with this. If they think they are stating something about the resource itself, well they would be wrong even if the current URI was an information resource. They apparently need to learn more about web technology - representations, caching, con-neg, c. (Indeed, they may know nothing about RDF.) But they still use http://iandavis.com/2010/303/toucan to identify the web page, and no amount of RDF can change that fact. Furthermore, their statements may eventually be translated to RDF -- perhaps by someone else -- and merged with other assertions that use http://iandavis.com/2010/303/toucan to refer to the toucan. OK, they might. Do you have any examples of problems with Ian's approach that are likely to happen at the moment? So I don't think it is reasonable or realistic to think that we can *avoid* creating an ambiguity by returning additional RDF statements with the 200 response. Rather, the heuristic that you propose is a way for applications to *deal* with that ambiguity by tracking the provenance of the information: if one set of assertions was derived from an HTTP 200 response code, and another set of assertions was derived from an RDF document that you trust, then ignore the assertions that were derived from the HTTP 200 response code. By not drawing ill-founded conclusions about the nature of the resource through the response code, ambiguity could have been avoided in the first place. Tore rEiksson ___ Tore Eriksson [tore.eriksson at po.rd.taisho.co.jp]
