Re: Decommissioning a linked data site
Folks- FWIW, I have now reimplemented and relaunched http://www.t4gm.infoas an unpublished linked data resource, with its behavior largely consistent with the discussion on this thread. The new site links to a Github repository https://github.com/bradleypallen/t4gm-unpublished, and the CKAN Data Hub entry has been updated to reflect the new site. - cheers, BPA Bradley P. Allen http://bradleypallen.org On Fri, Jun 8, 2012 at 5:39 AM, Antoine Isaac ais...@few.vu.nl wrote: On 6/8/12 1:53 PM, Richard Cyganiak wrote: On 6 Jun 2012, at 14:04, Antoine Isaac wrote: By the way, I've tried to update our DataHub entry at http://thedatahub.org/dataset/**stitch-rameauhttp://thedatahub.org/dataset/stitch-rameau, fitting decommissioned somewhere. I've just added it as a tag for now, I did not know which other fields I could use. A tag is fine. OK, thx, Richard! Antoine
Re: Decommissioning a linked data site
Leigh- This is great. The question that comes up for me out of what you've written for unpublishing brings me back to Antoine's question: is it appropriate to use a relation other than owl:sameAs that more specific to the domain of the affected datasets being mapped, or is the nature of unpublishing such that one would, as opposed to my reasoning earlier, be as broad as possible in asserting equivalence, and use owlsameAs in every such case? Bradley P. Allen http://bradleypallen.org On Fri, Jun 1, 2012 at 2:48 AM, Leigh Dodds le...@ldodds.com wrote: Hi, On Fri, Jun 1, 2012 at 7:34 AM, Antoine Isaac ais...@few.vu.nl wrote: @Tim: For total extra kudos, provide query rewriting rules from yours site to LoC data, linked so that you can write a program to start with a sparql query which fails and figures out from metadata how to turn it into one which works! Is the combination of 301 + owl:sameAs that we have used for RAMEAU, e.g, http://stitch.cs.vu.nl/vocabularies/rameau/ark:/12148/cb11932889r good enough? Or would you recommend more/different? I've started to capture some advice here: http://patterns.dataincubator.org/book/unpublish.html Cheers, L
Re: Decommissioning a linked data site
Tim- OK, I'm game. I am in the process of hacking together a small redirect server that would replace the existing site, and can easily incorporate the ability to return something like the following on a request for the root resource: @prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# . @prefix rdfs: http://www.w3.org/2000/01/rdf-schema# . @prefix foaf: http://xmlns.com/foaf/0.1/ . @prefix dcterms: http://purl.org/dc/terms/ . @prefix void: http://rdfs.org/ns/void# . @prefix skos: http://www.w3.org/2004/02/skos/core# . http://www.t4gm.info/ rdf:type void:Dataset ; foaf:homepage http://www.t4gm.info/ ; void:uriSpace http://www.t4gm.info/concept/; ; dcterms:isReplacedBy http://id.loc.gov/vocabulary/graphicMaterials . http://id.loc.gov/vocabulary/graphicMaterials rdf:type void:Dataset ; foaf:homepage http://id.loc.gov/vocabulary/graphicMaterials.html ; dcterms:replaces http://www.t4gm.info/ . http://www.t4gm.info/linkset/ rdf:type void:Linkset ; void:linkPredicate skos:exactMatch ; void:subjectsTarget http://www.t4gm.info/ ; void:objectsTarget http://id.loc.gov/vocabulary/graphicMaterials ; void:dataDump http://www.t4gm.info/linkset/ . Would something like that suffice? I think this captures the crucial information that there are two datasets, that one is replacing the other, and that (following Antoine's lead) we provide access to a linkset that maps resources from one dataset to its replacement. Additionally we could provide additional general voiD dataset metadata and provenance information to give additional background. I could not, however, find a vocabulary that made it easy to express the normative statement that http://id.loc.gov/vocabulary/graphicMaterials was in some manner better or to be preferred to http://www.t4gm.info/. The provenance vocabularies don't seem to address this question; the closest thing I can find are the predicates in and around stating opinions about scientific discourse in ontologies like SWAN. Perhaps this is an issue that could be taken up in the Open Provenance effort, if someone hasn't already addressed it. I'm regret to say that I'd already nuked the CKAN record by the time this email reached me, but I'll follow up and see what support there is there to provide a historical record with similar information for others proceeding down this path in the future. Finally, I'd like to try to do something to address your suggestion with respect to providing query rewrite rules, but I'm unclear exactly what you mean by that; what form would you expect that kind of information to take? - regards, BPA Bradley P. Allen http://bradleypallen.org On Wed, May 30, 2012 at 3:57 AM, Tim Berners-Lee ti...@w3.org wrote: Seems to me that the crucial bit of information that the data which is served by your site now can be got much better by going th LoC site woul dbe nice to have in machine readable form. One idea is *leaving* it in CKAN but mark it as historical so it can be a place o make the pointer the the superceding point. The entry could be a sort of rallying point for people who were interested in the data. In a way, the CKAN entry has an added value once you are gone. I don't know if CKAN has that facility. For total extra kudos, provide query rewriting rules from yours site to LoC data, linked so that you can write a program to start with a sparql query which fails and figures out from metadata how to turn it into one which works! Tim On 2012-05 -29, at 16:47, Antoine Isaac wrote: Dear Bradley, The second part of your plan reminds me of my recent question on moving a dataset http://lists.w3.org/Archives/Public/public-lod/2012Apr/0123.html The object moved (a thesaurus) is quite the same, as the cause for the moving: in both cases an official version has arisen to replace a first prototype. We have tried to create a redirection, using a 301 code. But I guess that if we had decided to shut done our server altogether, we would have opted for the same 410 code as you! and maybe we'll do, one day... Cheers, Antoine Back in 2009, as an experiment in working with RDFa and linked data, I created t4gm.info http://t4gm.info. It is based solely on US Library of Congress library linked data (specifically, the Thesaurus for Graphical Materials), which at the time I created the site didn't have any equivalently accessible linked data. That has long since been rectified by the LoC. So t4gm.info http://t4gm.info is at best redundant and at worst potentially confusing. So what I want to do is shut the site down. But there doesn't seem to be much if any best practice around doing that, especially when the site by virtue of its listing with CKAN is part of the LOD Cloud diagram. What I want to do is 1) delist it from CKAN, and then 2) shut the site down, perhaps replacing it with a simple web service returning a 410 status code per RFC 2616. I assume it will be removed from the LOD cloud
Re: Decommissioning a linked data site
Perfect. I was hoping that might be the case. I'll proceed to update the record. Bradley P. Allen http://bradleypallen.org On Wed, May 30, 2012 at 4:12 PM, Richard Cyganiak rich...@cyganiak.dewrote: Bradley, On 30 May 2012, at 23:03, Bradley Allen wrote: I'm regret to say that I'd already nuked the CKAN record by the time this email reached me CKAN doesn't actually nuke things that are deleted, it just hides them from view and they can be restored, which I just did for the t4gm dataset: http://thedatahub.org/dataset/t4gm-info Please update the record to reflect the fact that it's now only a “tombstone” for some data that is no longer available. We also need some way to mark this for the LOD Cloud. How about adopting a new tag “lodcloud.tombstone”? Thanks, Richard
Re: Decommissioning a linked data site
Antoine- Thanks for the pointer to the previous discussion, which I regret to say I had missed; the use case is almost the same and it is an approach that yields a softer landing in those cases where people/agents have been dependent on the resources being sunsetted. So I'm going to instead follow your lead and have t4gm.info instead respond with a 301 redirection to the equivalent id.loc.gov resource when that exists, else respond with a 410 error. - regards, BPA Bradley P. Allen http://bradleypallen.org On Tue, May 29, 2012 at 1:53 PM, Antoine Isaac ais...@few.vu.nl wrote: But I guess that if we had decided to shut done our server altogether I mean, shut down our vocabulary server, which handles the queries for data on individual concepts. Which would leave us with just the ability to serve a same answer for the entire domain... Antoine Dear Bradley, The second part of your plan reminds me of my recent question on moving a dataset http://lists.w3.org/Archives/**Public/public-lod/2012Apr/**0123.htmlhttp://lists.w3.org/Archives/Public/public-lod/2012Apr/0123.html The object moved (a thesaurus) is quite the same, as the cause for the moving: in both cases an official version has arisen to replace a first prototype. We have tried to create a redirection, using a 301 code. But I guess that if we had decided to shut done our server altogether, we would have opted for the same 410 code as you! and maybe we'll do, one day... Cheers, Antoine Back in 2009, as an experiment in working with RDFa and linked data, I created t4gm.info http://t4gm.info. It is based solely on US Library of Congress library linked data (specifically, the Thesaurus for Graphical Materials), which at the time I created the site didn't have any equivalently accessible linked data. That has long since been rectified by the LoC. So t4gm.info http://t4gm.info is at best redundant and at worst potentially confusing. So what I want to do is shut the site down. But there doesn't seem to be much if any best practice around doing that, especially when the site by virtue of its listing with CKAN is part of the LOD Cloud diagram. What I want to do is 1) delist it from CKAN, and then 2) shut the site down, perhaps replacing it with a simple web service returning a 410 status code per RFC 2616. I assume it will be removed from the LOD cloud diagram when that is next updated from the CKAN data. Anyone have any suggestions beyond that? Also, if anyone from CKAN is reading this, I could also use some guidance on how deletion of records is accomplished through the online interface. - cheers, BPA Bradley P. Allen http://bradleypallen.org
Decommissioning a linked data site
Back in 2009, as an experiment in working with RDFa and linked data, I created t4gm.info. It is based solely on US Library of Congress library linked data (specifically, the Thesaurus for Graphical Materials), which at the time I created the site didn't have any equivalently accessible linked data. That has long since been rectified by the LoC. So t4gm.info is at best redundant and at worst potentially confusing. So what I want to do is shut the site down. But there doesn't seem to be much if any best practice around doing that, especially when the site by virtue of its listing with CKAN is part of the LOD Cloud diagram. What I want to do is 1) delist it from CKAN, and then 2) shut the site down, perhaps replacing it with a simple web service returning a 410 status code per RFC 2616. I assume it will be removed from the LOD cloud diagram when that is next updated from the CKAN data. Anyone have any suggestions beyond that? Also, if anyone from CKAN is reading this, I could also use some guidance on how deletion of records is accomplished through the online interface. - cheers, BPA Bradley P. Allen http://bradleypallen.org
JSON-LD requirements
Gregg- I think this is nicely done and a great contribution to Monday's call, but I have some comments on terminology as it relates to section 3.1. In item 2 of the numbered list in that section, the phrase conceptional graph appears; I assume that's a typo for the phrase conceptual graph, which is used in items 7 and 9. That being said, I think the use of conceptual graph in this context is problematic; that term is traditionally used to refer to the formalism developed by John Sowa in his work on knowledge representation, and implies a great deal more than I think you intend here; see Berners-Lee's writing on the differences between the CG formalism and RDF at http://www.w3.org/DesignIssues/CG.html. I would suggest replacing conceptual graph with directed graph, which I believe communicates your intent precisely without any unintended KR baggage. - FWIW, BPA On Saturday, July 2, 2011, Gregg Kellogg gr...@kellogg-assoc.com wrote: gt; In order to try to reach some common ground, I put together a JSON-LD requirements document [1]. My thought was that we could look at the items point by point for the monday conference call to see where we have common ground. gt; gt; I've doubtless left off some requirements that other's would like to see; if there's something you'd like to add let me know and I'll update the doc. gt; gt; Gregg gt; gt; [1] http://json-ld.org/requirements/latest/ gt; -- Bradley P. Allen http://bradleypallen.org
Re: Status codes / IR vs. NIR -- 303 vs. 200
Nathan- I think you are overly discounting scalability problems with fragment URIs. Most of the use cases I am dealing with in moving linked data into production at Elsevier entail SKOS concept schemes with concepts numbering in the 100,000's to millions, which will be constantly under curation, preferably using REST APIs that allow POSTs and PUTs to create and update individual concepts. Can you articulate a reasonable way in which that can be accomplished using fragment URIs? - regards, BPA Bradley P. Allen http://bradleypallen.org On Wed, Nov 10, 2010 at 12:11 PM, Nathan nat...@webr3.org wrote: Lars Heuer wrote: Which solution gives less black spots? fragments, with approx zero black spots (still to see a valid argument against them, vs more than i can list for non fragments)
Re: Status codes / IR vs. NIR -- 303 vs. 200
The assumption then would be that each representation would in the limit have a corresponding fragment URI. Correct? Bradley P. Allen http://bradleypallen.org On Wed, Nov 10, 2010 at 1:09 PM, Nathan nat...@webr3.org wrote: exactly the same way, you GET,PUT,POST,PATCH,DELETE descriptions.. PUT /resource1 unless of course you mean, if I have 100,000 concepts described by a single representation, how do I update it RESTfully, in which case the answer is clearly, don't put 100,000 concepts in a single representation. as in, do things exactly the same way you do now, whatever works for you - using a fragment has no bearing on anything REST-related, unless as I say, you decide it's a good idea to drop a full db/store in to one representation (which I'd suggest isn't a good idea!) ps: PATCH isn't the best idea unless you've got some good skolemization Best, Nathan Bradley Allen wrote: Nathan- I guess I'm not being clear about my problem. How do you get a REST API to work with fragment URIs? - BPA Bradley P. Allen http://bradleypallen.org On Wed, Nov 10, 2010 at 12:33 PM, Nathan nat...@webr3.org wrote: Bradley Allen wrote: Nathan- I think you are overly discounting scalability problems with fragment URIs. Most of the use cases I am dealing with in moving linked data into production at Elsevier entail SKOS concept schemes with concepts numbering in the 100,000's to millions, which will be constantly under curation, preferably using REST APIs that allow POSTs and PUTs to create and update individual concepts. Can you articulate a reasonable way in which that can be accomplished using fragment URIs? - regards, BPA /resource1 /resource2 /resource3 /resource1#1 /resource2#2 /resource3#3 with the additional benefit that you can do /resourcea#1 /resourcea#2 /resourceb#1 /resourceb#2 as in, exactly the same way, but with *more* options.
Re: Status codes / IR vs. NIR -- 303 vs. 200
I'm not making a distinction between HTML and RDF/XML files in this discussion, as either can be containers of RDF statements about resources. If I want to use REST as a way to update statements about an NIR named with a fragment URI using whatever serialization, since I can only update slash URIs then there is some machinery or pattern in place that allows you to determine what slash URI to use to update the statements. What I'm looking for what you do to make that unproblematic. Bradley P. Allen http://bradleypallen.org On Wed, Nov 10, 2010 at 2:00 PM, Nathan nat...@webr3.org wrote: Please tell me that you're not trying to infer that using the HyperText Transfer Protocol to update an HTML document which describes the staff in a staff-of-three company, similar to the following, is RESTful: http://example.org/staff#mary http://example.org/staff#bob http://example.org/staff#bill == PUT http://example.org/staff But updating an RDF document, for the same company, containing the same descriptions, of the same three people, identified by the same three URIs, is somehow un-RESTful: http://example.org/staff#mary http://example.org/staff#bob http://example.org/staff#bill == PUT http://example.org/staff Or are you saying that updating a description of one person, (supposedly) identified by the URI http://example.org/people/sue, is RESTful: PUT http://example.org/people/sue but updating a description of one person, identified by the URI http://example.org/people/sue#me, is un-RESTful: PUT http://example.org/people/sue ps: I use fragments, and update descriptions RESTfully, never ever had a problem yet. Regards, Nathan Bradley Allen wrote: The assumption then would be that each representation would in the limit have a corresponding fragment URI. Correct? Bradley P. Allen http://bradleypallen.org On Wed, Nov 10, 2010 at 1:09 PM, Nathan nat...@webr3.org wrote: exactly the same way, you GET,PUT,POST,PATCH,DELETE descriptions.. PUT /resource1 unless of course you mean, if I have 100,000 concepts described by a single representation, how do I update it RESTfully, in which case the answer is clearly, don't put 100,000 concepts in a single representation. as in, do things exactly the same way you do now, whatever works for you - using a fragment has no bearing on anything REST-related, unless as I say, you decide it's a good idea to drop a full db/store in to one representation (which I'd suggest isn't a good idea!) ps: PATCH isn't the best idea unless you've got some good skolemization Best, Nathan Bradley Allen wrote: Nathan- I guess I'm not being clear about my problem. How do you get a REST API to work with fragment URIs? - BPA Bradley P. Allen http://bradleypallen.org On Wed, Nov 10, 2010 at 12:33 PM, Nathan nat...@webr3.org wrote: Bradley Allen wrote: Nathan- I think you are overly discounting scalability problems with fragment URIs. Most of the use cases I am dealing with in moving linked data into production at Elsevier entail SKOS concept schemes with concepts numbering in the 100,000's to millions, which will be constantly under curation, preferably using REST APIs that allow POSTs and PUTs to create and update individual concepts. Can you articulate a reasonable way in which that can be accomplished using fragment URIs? - regards, BPA /resource1 /resource2 /resource3 /resource1#1 /resource2#2 /resource3#3 with the additional benefit that you can do /resourcea#1 /resourcea#2 /resourceb#1 /resourceb#2 as in, exactly the same way, but with *more* options.
Re: Status codes / IR vs. NIR -- 303 vs. 200
Thanks; that's a useful example. So the convention in that case is to append '#concept' to the end of the IR? Bradley P. Allen http://bradleypallen.org On Wed, Nov 10, 2010 at 3:07 PM, Toby Inkster t...@g5n.co.uk wrote: On Wed, 10 Nov 2010 12:30:35 -0800 Bradley Allen bradley.p.al...@gmail.com wrote: Nathan- I think you are overly discounting scalability problems with fragment URIs. Most of the use cases I am dealing with in moving linked data into production at Elsevier entail SKOS concept schemes with concepts numbering in the 100,000's to millions, which will be constantly under curation, preferably using REST APIs that allow POSTs and PUTs to create and update individual concepts. The Library of Congress Subject Headings consist of over a quarter of a million SKOS concepts. They use hash URIs. e.g. http://id.loc.gov/authorities/sh85121735#concept http://id.loc.gov/authorities/sh85121591#concept http://id.loc.gov/authorities/sh85119315#concept http://id.loc.gov/authorities/sh86001831#concept http://id.loc.gov/authorities/sh85072413#concept -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: Status codes / IR vs. NIR -- 303 vs. 200
Toby- A quick correction: in the previous email, by end of the IR I meant to say end of the IR's URI. I note also that the LC's Thesaurus of Graphic Materials uses slash URIs instead of hash URIs. e.g. http://id.loc.gov/vocabulary/graphicMaterials/tgm003862 http://id.loc.gov/vocabulary/graphicMaterials/tgm13 http://id.loc.gov/vocabulary/graphicMaterials/tgm002276 http://id.loc.gov/vocabulary/graphicMaterials/tgm004048 http://id.loc.gov/vocabulary/graphicMaterials/tgm005114 I'm curious as to why the LC would use two different schemes in this regard. Bradley P. Allen http://bradleypallen.org On Wed, Nov 10, 2010 at 3:13 PM, Bradley Allen bradley.p.al...@gmail.com wrote: Thanks; that's a useful example. So the convention in that case is to append '#concept' to the end of the IR? Bradley P. Allen http://bradleypallen.org On Wed, Nov 10, 2010 at 3:07 PM, Toby Inkster t...@g5n.co.uk wrote: On Wed, 10 Nov 2010 12:30:35 -0800 Bradley Allen bradley.p.al...@gmail.com wrote: Nathan- I think you are overly discounting scalability problems with fragment URIs. Most of the use cases I am dealing with in moving linked data into production at Elsevier entail SKOS concept schemes with concepts numbering in the 100,000's to millions, which will be constantly under curation, preferably using REST APIs that allow POSTs and PUTs to create and update individual concepts. The Library of Congress Subject Headings consist of over a quarter of a million SKOS concepts. They use hash URIs. e.g. http://id.loc.gov/authorities/sh85121735#concept http://id.loc.gov/authorities/sh85121591#concept http://id.loc.gov/authorities/sh85119315#concept http://id.loc.gov/authorities/sh86001831#concept http://id.loc.gov/authorities/sh85072413#concept -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: Is 303 really necessary?
Basically what you are saying is: if I have a single URI that responds to an HTTP GET with (X)HTML+RDFa by default, and supports other RDF serializations through content negotiation, then all of that can be done without recourse to a 303 redirect and should be perfectly compatible with linked data best practice. Is that correct? Bradley P. Allen http://bradleypallen.org On Thu, Nov 4, 2010 at 8:58 AM, Ian Davis m...@iandavis.com wrote: On Thu, Nov 4, 2010 at 3:50 PM, Giovanni Tummarello giovanni.tummare...@deri.org wrote: I think it's an orthogonal issue to the one RDFa solves. How should I use RDFa to respond to requests to http://iandavis.com/id/me which is a URI that denotes me? hashless? mm one could be to return HTML + RDFa describing yourself. add a triple saying http://iandavis.com/id/me containstriplesonlyabouttheresourceandnoneaboutitselfasinformationresource Yes, that's basically what I'm saying in my blog post. its up to clients to really care about the distinction, i personally know of no useful clients for the web of data that will visibly misbehave if a person is mistaken for a page.. so your you can certify to your customer your solution works well with any client Good to know. That's my sense too. if one will come up which operates usefully on both people and pages and would benefit from making your distinction than those coding that client will definitely learn about your containstriplesonlyabouttheresourceandnoneaboutitselfasinformationresource and support it. how about this ? :-) Sounds good to me :) as an alternative the post i pointed you earlier (the one about 203 406) did actually contain an answer i believe. 406 is perfect IMO .. I'd say a client which will care to make the distinction would learn to support it as in my previous example. I'll look into that. Ian
Re: Is 303 really necessary?
On Thu, Nov 4, 2010 at 9:13 AM, Ian Davis m...@iandavis.com wrote: On Thu, Nov 4, 2010 at 4:07 PM, Bradley Allen bradley.p.al...@gmail.com wrote: Basically what you are saying is: if I have a single URI that responds to an HTTP GET with (X)HTML+RDFa by default, and supports other RDF serializations through content negotiation, then all of that can be done without recourse to a 303 redirect and should be perfectly compatible with linked data best practice. That is what I would like to see and what I believe is possible. It's not current practice, so I'm seeking a change. I am in violent agreement. It is long past due that someone made this point. As has been said been said earlier, this simplifies implementation, eliminates unnecessary traffic and is completely transparent to linked data clients that do content negotiation. - BPA Bradley P. Allen http://bradleypallen.org
Fwd: Is 303 really necessary?
Kingsley- I didn't say I had ever lost this option. My problem is that this simpler option is not acknowledged as a legitimate best practice, which it is, in my opinion. - BPA Bradley P. Allen http://bradleypallen.org On Thu, Nov 4, 2010 at 12:12 PM, Kingsley Idehen kide...@openlinksw.com wrote: On 11/4/10 12:25 PM, Bradley Allen wrote: On Thu, Nov 4, 2010 at 9:13 AM, Ian Davis m...@iandavis.com wrote: On Thu, Nov 4, 2010 at 4:07 PM, Bradley Allen bradley.p.al...@gmail.com wrote: Basically what you are saying is: if I have a single URI that responds to an HTTP GET with (X)HTML+RDFa by default, and supports other RDF serializations through content negotiation, then all of that can be done without recourse to a 303 redirect and should be perfectly compatible with linked data best practice. That is what I would like to see and what I believe is possible. It's not current practice, so I'm seeking a change. I am in violent agreement. It is long past due that someone made this point. As has been said been said earlier, this simplifies implementation, eliminates unnecessary traffic and is completely transparent to linked data clients that do content negotiation. - BPA Bradley P. Allen http://bradleypallen.org Bradley, When did you loose this option? (X)HTML+RDFa is another mechanism structured data representation. One that doesn't mandate Apache (bottom line) for deployment. Just drop the resource wherever, and you're done re. your Web of Linked Data contribution. 303 redirection has never been a mandate. Separating Names from Addresses has, and should be a mandate -- assuming this is where this debate is headed. -- Regards, Kingsley Idehen President CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Looking for skos:subject replacement
Folks- I'm looking for a relation with domain skos:Concept or one of its superclasses that can replace what skos:subject originally stood for; effectively, the inverse of dc:subject. Interestingly, AFAICT neither of DC*, SIOC, SALT or BIBO have something like this. foaf:publications is close but has domain foaf:Person. I see where Joachim Neubert in his conversion of the Thesaurus of Economics to SKOS (http://events.linkeddata.org/ldow2009/papers/ldow2009_paper7.pdf) was forced to invent his own (zbwext:indexedItem) but I'm looking for something more broadly adopted. Richard Cygniak's advice (http://dowhatimean.net/2006/06/an-rdf-design-pattern-inverse-property-labels) to use anonymous inverse properties, if I'm not mistaken, doesn't work so well in an RDFa serialization, which is a use case I'm trying to accommodate. Any other ideas before I'm forced to go Joachim's route? - cheers, BPA Bradley P. Allen http://bradleypallen.org +1 310 951 4300
Re: Best practices: representing homonym relationships in SKOS
Thomas and Karl- Thanks for the leads; this gives us something to run with. To Karl's point, our principal concern is with homographs. Even though the approach outlined introduces classes to deal with labels it is perhaps the only principled way to do this type of thing, and at least we won't have to be reinvent the vocabulary wheel, so to speak. I am embarrassed to say that I had not clued into the SKOS(XL) effort up to this point; I suppose I have some archive reading to do. - regards, BPA Bradley P. Allen http://bradleypallen.org +1 310 951 4300 On Sat, Nov 14, 2009 at 11:10 AM, Thomas Bandholtz thomas.bandho...@innoq.com wrote: Hi Bradley, thanks a lot for raising this question, as currently we have discussions about different approaches of Label management in SKOS(XL), and the homograph issue has been somehow neglected so far. Karl has mentioned the difference between homographs and homophones already. I would say: homographs - same spelling, different meaning (graph has nothing to do with an RDF graph in this case). homophones - same sound (phonetics), different meaning. As SKOS(XL) is dealing with lexical aspects (literal form) rather than with phonetics (at least so far), we have to care for homographs at first. One example: bass [fish] and bass [music], which are about bass as a homograph (not a homophone). You see I used some kind of qualifier to distinguish the two meanings. This is a common practise, not a standard. In SKOS you may say: A a skos:Concept ; skos:prefLabel bass [fish] . B a skos:Concept ; skos:prefLabel bass [music] . You might also drop the qualifiers: A a skos:Concept ; skos:prefLabel bass . B a skos:Concept ; skos:prefLabel bass . Then express the different meanings by some semantic relation to a more specific thing for each of them: A skos:related fishConcept . B skos:related musicConcept . There is absolutely no semantic relation between A and B, it is only a lexical relation. Such a lexical relation you can express in SKOSXL in detail (if you want to do so at all). In UMTHES we use the following pattern: A a skos:Concept ; skosxl:prefLabel bass--fish . B a skos:Concept ; skosxl:prefLabel bass--music . bass--fish a skosxl:Label ; skosxl:literalForm bass [fish] ; umt:homograph bass ; umt:qualifier fish . bass--music a skosxl:Label ; skosxl:literalForm bass [music] ; umt:homograph bass ; umt:qualifier music . bass a skosxl:Label ; skosxl:literalForm bass . fish a skosxl:Label ; skosxl:literalForm fish . music a skosxl:Label ; skosxl:literalForm music . where umt:homograph and umt:qualifier both are subProperties of skosxl:labelRelation. Note that we have only one label bass here, as we think that semantics are in the Concepts, not in the Labels. Labels are dumb character strings only. Well, I would be curious to see more examples from different vocabularies. Best regards, Thomas Bradley Allen schrieb: Apologies if you've seen this on the LOD or SW lists, but it is probably better posed to this audience: is there any best practice or, failing that, good ideas for representing homonymy in SKOS? Best I can come up with is subclassing skos:semanticRelation with something like skos:homonym, and letting the client sort out which of the lexical labels might be involved. Not excited about the need to go to a class representation for labels; even less interested in anything involving RDF collections. - cheers, BPA Bradley P. Allen http://bradleypallen.org +1 310 951 4300 -- Thomas Bandholtz, thomas.bandho...@innoq.com, http://www.innoq.com innoQ Deutschland GmbH, Halskestr. 17, D-40880 Ratingen, Germany Phone: +49 228 9288490 Mobile: +49 178 4049387 Fax: +49 228 9288491
Best practices: representing homonym relationships in SKOS
Twitter failed to cough up an answer, so I'll try the lists: is there any best practice or, failing that, good ideas for representing homonymy in SKOS? Best I can come up with is subclassing skos:semanticRelation with something like skos:hasHomonym, and letting the client sort out which of the lexical labels might be involved. Not excited about the need to go to a class representation for labels; even less interested in anything involving RDF collections. - cheers, BPA Bradley P. Allen http://bradleypallen.org +1 310 951 4300
Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation
Kingsley- On Fri, Jun 26, 2009 at 11:40 AM, Kingsley Idehenkide...@openlinksw.com wrote: Mark: Should we be describing our docs for Google, fundamentally? I really think Google should actually recalibrate back to the Web etc.. The correct question to ask, and the one that I believe Mark is addressing, is should we be asking people to describe their content in a way that may be at cross-purposes to their efforts to monetize it? Bradley P. Allen http://bradleypallen.org +1 310 951 4300
Re: RDFa vs RDF/XML and content negotiation
I agree that both is better, but there is a catch. As did Toby with his system, in http://t4gm.info, I serve up both XHTML+RDFa and perform content negotiation, generating triples in the MIME type expected by a given RDF-accepting user agent by redirecting the given static XHTML+RDFa page through the RDFa Distiller service. The main issue with this, however, was configuring this in Apache on the hosting provider I use resulted in a solution based on .htaccess that does not respect quality values. I am not currently aware of a working solution to this problem. Doing content negotiation in a completely correct manner presupposes a level of expertise and control over the server side that is not available to everyone who could be fruitfully producing XHTML+RDFa, serving it up with a vanilla HTTP server or embedding it in a hosted blog post. - cheers, BPA Bradley P. Allen http://bradleypallen.org +1 310 951 4300 On Tue, Jun 23, 2009 at 3:31 PM, Kingsley Idehenkide...@openlinksw.com wrote: Bill Roberts wrote: Thanks everyone who replied. It seems that there's a lot of support for the RDFa route in that (perhaps not statistically significant) sample of opinion. But to summarise my understanding of your various bits of advice: since there aren't currently so many applications out there consuming RDF, a good RDF publisher should provide as many options as possible. Amen! Therefore rather than deciding for either RDFa or a content-negotiated approach, why not do both (and provide a dump file too) Exactly! RDFa vs Content Negotiation is a misnomer re. Web Architecture :-) Kingsley Cheers Bill -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com
Re: Can we lower the LD entry cost please (part 1)?
This is one of the issues I am trying to address with http://t4gm.info. There the notion of autocomplete filtering for SKOS concepts combined with content negotiation allows one to have one's cake and eat it too, at least as far user-friendly URL lookup is concerned; because of the use of XHTML+RDFa, the retrieved page is both human- and machine-readable. - BPA Bradley P. Allen http://bradleypallen.org +1 310 951 4300 On Sat, Feb 7, 2009 at 7:19 AM, Michael Hausenblas michael.hausenb...@deri.org wrote: FWIF, my 0.02€: I think Hugh has a point there: lower the barrier for interested people in the domain to chip in. Hence, an entry point should be provided, which is simple enough to be used by quite everyone. Experience (in the realm of linked data applications) tells that it is quite always the case that you start in a 'non-semantic' space. This might be a keyword, a melody in your head or a still image on a Web site. So, let me try to generalise and rephrase (one of) Hugh's questions (I'm sure he will tell me if I've done wrong ;) ... How can one enter the 'semantic space' (where RDF, etc. Rules) given a keyword, a concept, an image, etc.? Cheers, Michael -- Dr. Michael Hausenblas DERI - Digital Enterprise Research Institute National University of Ireland, Lower Dangan, Galway, Ireland, Europe Tel. +353 91 495730 http://sw-app.org/about.html From: Hugh Glaser h...@ecs.soton.ac.uk Date: Sat, 7 Feb 2009 13:23:44 + To: Linked Data community public-lod@w3.org Subject: Can we lower the LD entry cost please (part 1)? Resent-From: Linked Data community public-lod@w3.org Resent-Date: Sat, 07 Feb 2009 13:24:39 + My proposal: *We should not permit any site to be a member of the Linked Data cloud if it does not provide a simple way of finding URIs from natural language identifiers.* Rationale: One aspect of our Linking Data (not to mention our Linking Open Data) world is that we want people to link to our data - that is, I have published some stuff about something, with a URI, and I want people to be able to use that URI. So my question to you, the publisher, is: How easy is it for me to find the URI your users want? My experience suggests it is not always very easy. What is required at the minimum, I suggest, is a text search, so that if I have a (boring string version of a) name that refers in my mind to something, I can hope to find an (exciting Linked Data) URI of that thing. I call this a projection from the Web to the Semantic Web. rdfs:label or equivalent usually provides the other one. At the risk of being seen as critical of the amazing efforts of all my colleagues (if not also myself), this is rarely an easy thing to do. Some recent experiences: OpenCalais: as in my previous message on this list, I tried hard to find a URI for Tim, but failed. dbtune: Saw a Twine message about dbtune, trundled over there, and tried to find a URI for a Telemann, but failed. dbpedia: wanted Tim again. After clicking on a few web pages, none of which seemed to provide a search facility, I resorted to my usual method:- look it up in wikipedia and then hack the URI and hope it works in dbpedia. (Sorry to name specific sites, guys, but I needed a few examples. And I am only asking for a little more, so that the fruits of your amazing labours can be more widely appreciated!) wordnet: [2] below So I have access to Linked Data sites that I know (or at least strongly suspect) have URIs I might want, but I can't find them. How on earth do we expect your average punter to join this world? What have I missed? Searching, such as Sindice: Well yes, but should I really have to go off to a search engine to find a dbpedia URI? And when I look up Telemann dbtune I don't get any results. And I wanted the dbtune link, not some other link. Did I miss some links on web pages? Quite probably, but the basic problem still stands. SPARQL: Well, yes. But we cannot seriously expect our users to formulate a SPARQL query simply to find out the dbpedia URI for Tim. What is the regexp I need to put in? (see below [1]) A foaf file: Well Tim's dbpedia URI is probably in his foaf file (although possibly there are none of Tim's URIs in his foaf file), if I can actually find the file; but for some reason I can't seem to find Telemann's foaf file. If you are still doubting me, try finding a URI for Telemann in dbpedia without using an external link, just by following stuff from the home page. I managed to get a Telemann by using SPARQL without a regexp (it times out on any regexp), but unfortunately I get the asteroid. Again, my proposal: *We should not permit any site to be a member of the Linked Data cloud if it does not provide a simple way of finding URIs from natural language identifiers.* Otherwise we end up in a silo, and the world passes us
Re: [ANN] t4gm.info: a Linked Data rendering of the Thesaurus of Graphic Materials
Tom- Certainly not for organizational reasons; I've built this site on my own time and am hosting it on my own nickel. I'd be open to working out how to mirror the content at other sites to reduce the risk of loss of service, since modulo the prefix matching API it is largely static content. I'd be interested to hear what people thought about LOD best practice for doing so; I assume that some stitching overlay using owl:sameAs would suffice. Clearly, as the lcsh.info episode makes clear, this would be useful. - regards, BPA Bradley P. Allen http://bradleypallen.org +1 310 951 4300 On Mon, Jan 19, 2009 at 3:15 AM, Tom Heath tom.he...@talis.com wrote: Bradley, As Kingsley says, very cool! Is there any risk of this going the same way as lcsh.info? :( Hope not, Tom. 2009/1/15 Kingsley Idehen kide...@openlinksw.com: On 1/14/09 6:13 AM, Bradley Allen wrote: t4gm.info http://www.t4gm.info is a simple, lightweight and DRY http://en.wikipedia.org/wiki/DRY Linked Open Data rendering in XHTML+RDFa of the Library of Congress http://www.loc.gov/index.html' Thesaurus for Graphic Materials http://lcweb2.loc.gov/pp/tgmhtml/tgmabt.html. Details about its use and implementation can be found on its help page http://www.t4gm.info/help. Comments to the undersigned are welcomed. - regards, BPA Bradley P. Allen http://bradleypallen.org +1 310 951 4300 Bradley, Very cool!! -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehenhttp://www.openlinksw.com/blog/%7Ekidehen President CEO OpenLink Software Web: http://www.openlinksw.com Please consider the environment before printing this email. Find out more about Talis at www.talis.com shared innovationTM 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. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- Dr Tom Heath Researcher Platform Division Talis Information Ltd T: 0870 400 5000 W: http://www.talis.com/
[ANN] t4gm.info: a Linked Data rendering of the Thesaurus of Graphic Materials
t4gm.info http://www.t4gm.info is a simple, lightweight and DRYhttp://en.wikipedia.org/wiki/DRYLinked Open Data rendering in XHTML+RDFa of the Library of Congress http://www.loc.gov/index.html' Thesaurus for Graphic Materialshttp://lcweb2.loc.gov/pp/tgmhtml/tgmabt.html. Details about its use and implementation can be found on its help pagehttp://www.t4gm.info/help. Comments to the undersigned are welcomed. - regards, BPA Bradley P. Allen http://bradleypallen.org +1 310 951 4300
