- From: Andrea Splendiani <andrea.splendiani@iscb.org>
- Date: Wed, 29 May 2013 02:01:44 +0100
- To: Alan Ruttenberg <alanruttenberg@gmail.com>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, "public-semweb-lifesci@w3.org" <public-semweb-lifesci@w3.org>
- Message-Id: <EA52E504-56B0-4185-9829-946CC32E0FC9@iscb.org>
Il giorno 29/mag/2013, alle ore 01:27, Alan Ruttenberg <alanruttenberg@gmail.com> ha scritto: > > > On Tuesday, May 28, 2013, Andrea Splendiani wrote: > HI, > > perhaps a key makes easier to track usage for someone with whom you have established a contract (so servers/IPs may vary, but the "key" recorded is the same). > > I recall no contract offers. I mean, it's a common mechanism to support tracking in situations like where there is a contract. I'm not saying this is the reason bioportal adopted it. > > > I think it's an easy mechanism to pick up: if you want to maximize users... this is what any web-developer will do without thinking. > > If you want more users you make your resource better. Tracking allows reporting not recruiting. Nope. If you want more users you need to make resources simpler. Perhaps if you want "better" users you need to make resources better. Obviously better and simpler is... better ;) > > More complex schemes may push some people away: definitively not what you want in this area! (as reminder... many users of biportal may not be that tech-savy). > > I know. More the reason to set a good example. What you says below makes sense. My "pseudo use case" was the following: you provide a very stable and well maintained URI for http://you/youknowwhat Now, I'm adding lot of extra information to http://you/youknowwhat. No problem if this information is in a triple-store, but if I want to use a linked data frontend, I'm moreor less forced to have my URI for http://you/youknowwhat (In sense, mine would be an access-uri, not really an identifier as all that is returned could predicate on http://you/youknowwhat). As I said... just a curiosity on your approach. ciao, Andrea > > > Rewriting URIs... > What if you want to expose as Linked-Data (RESTy) third party data ? You need at least to provide new URIs with redirection... or not ? (not that this is the case of Bioportal,, just a curiosity). > > First do your best to enable the contributors to own and maintain their domain. Second, where users already have resource URIs, make clear that republishing are not the resource. Distinguish the republished linked data from the original - make clear that they are information objects *about* the resources. > > Where original publishers already produce rdf, add assertions if there is more you think it would be useful to say but make sure the provenance is clear - there are several reasonable ways. > > For simple cases where all that is desired is to have your own page about the resource too, consider adding either an annotated foaf:page property or a documented subproperty of foaf:page. Then politely ask your favourite linked data browser maker (that's you Kingsley) to offer to navigate (perhaps in a frame so that RDF can still be provided) to foaf:page so annotated instead of displaying what the linked data browser would natively display. > > In other words, try to find ways of adding linked data that acknowledge the publisher, anticipates that they might want to get into the linked data game later, with their own URIs, > be a bit careful about statements to so as not to make it impossible to tell what's what. > > FWIW, if there publishers who wish to have pages as alternatives to the ones that the Foundry produces, provide us a file of foaf:page (or similar) annotations which we can load into our store and thereafter provide. Make sure to give the targets of these annotations rdfs:labels, so they display something that entices the user to click them... > > -Alan > > > best, > Andrea > > Il giorno 28/mag/2013, alle ore 23:51, Alan Ruttenberg <alanruttenberg@gmail.com> ha scritto: > >> >> On May 28, 2013, at 6:23 PM, Kingsley Idehen <kidehen@openlinksw.com> wrote: >> >>> On 5/28/13 5:04 PM, Richard Boyce wrote: >>>> I think this helps bioportal keep track of usage (to justify its existence) and reduce annoying bots. Also, I get updates from bioportal for having registered an account. -R >>> >>> Bots are annoying, but they are part of the ecosystem. >>> API keys are archaic and quite contradictory an RDF based Linked Data realm. >> >> Yup. There are more clever ways of accomplishing the desired goals outside inconveniencing every user with an api key. Seems to me the goals also have to do with tracking the usage of the URIs and the users of the resource. >> >> I have tried to advise the Bioportal team about the basic of linked data norms and etiquette in the past, but they seem to be slow to progress along the learning curve. Kingsley, may I suggest that you give specific advise on where changes would be desirable. I would start by paying particular attention to cases where bioportal URIs duplicate authoritative URIs given by the authors of the resources they aggregate. For example, Chris points out that OBO Foundry URIs are intended to be linked data friendly, and certainly Bioportal should not be rewriting these. But I'm sure you can give plenty of other advise that might help them learn the finer points. >> >> I remain, as always, at their disposal. >> >> Regards, >> Alan >> >>> >>> RDF is about structured data enhanced with entity relationship semantics. If one actually looks to dog-food RDF you end up with solution to this broadly exposed problem. All that's required here is the construct RDF based data access policies that are driven by entity relationship semantics. >>> >>> Links: >>> >>> 1. http://www.w3.org/wiki/WebAccessControl -- Web Access Controls >>> 2. http://bit.ly/M7hd4T -- protecting SPARQL endpoints using RDF based entity relationship semantics >>> 3. http://bit.ly/UuWZSI -- collection of posts about ACLs and Data Access policies. >>> >>> >>> >>> Kingsley >>>> >>>> On 05/28/2013 04:54 PM, Jim McCusker wrote: >>>>> I can see asking for an API key for working with computational resources (like Annotator and Ontology Recommender), but we don't need an API key to see those classes in HTML, why should we need one to see them in RDF? >>>>> >>>>> Jim >>>>> >>>>> >>>>> On Tue, May 28, 2013 at 4:07 PM, Peter Ansell <ansell.peter@gmail.com> wrote: >>>>> Hi Kingsley, >>>>> >>>>> I think you may need an API key to work with them? [1] >>>>> >>>>> Cheers, >>>>> >>>>> Peter >>>>> >>>>> [1] http://www.bioontology.org/wiki/index.php/NCBO_REST_services >>>>> >>>>> >>>>> On 29 May 2013 05:55, Kingsley Idehen <kidehen@openlinksw.com> wrote: >>>>> All, >>>>> >>>>> Who are the folks responsible for URIs such as: >>>>> >>>>> 1. <http://purl.bioontology.org/ontology/NCIM/C0144157> ? >>>>> 2. < >
Received on Wednesday, 29 May 2013 01:02:09 UTC