- From: Leo Sauermann <leo.sauermann@gnowsis.com>
- Date: Sat, 12 Jun 2010 16:13:22 +0200
- To: Simon Cox <simon.cox@jrc.ec.europa.eu>
- CC: 'Alistair Miles' <alimanfoo@googlemail.com>, public-esw-thes@w3.org
coolness is not some theoretical concept but well defined in TimBls original "Cool URIs" article and our "Cool URIs for the Semantic Web" IG group note. your question is answered there, mostly it depends on the size of the ontology and the change rate you talk about. but this is essentially the same recs given by the SWBP vocab-publishing recs. links to all of those docs are given in www.w3.org/TR/cooluris/ I would recommend reading these docs and then come up with answers, this question is not new and has been thouroughly answered for the question of publishing vocabs before, all of the arguments given there apply also for SKOS and there is not much to find by munging it here forever :-) best Leo It was Simon Cox who said at the right time 11.06.2010 09:39 the following words: > # URIs implicitly embody a parent-child relationship, so in that case it is > clear. > But # URIs are not processed on the server-side - the server can't address a > secondary resource directly using a # URI. > > (How do # URIs work in triple stores?) > > For large ontologies we prefer / URIs. > Which is where the original question in this thread came from. > Clarifying it a bit: > Is it also smart to mint / URIs to be 'cool', in the sense that they show > the parent-child relationship. > > -------------------------------------------------------- > Simon Cox > > European Commission, Joint Research Centre > Institute for Environment and Sustainability > Spatial Data Infrastructures Unit, TP 262 > Via E. Fermi, 2749, I-21027 Ispra (VA), Italy > Tel: +39 0332 78 3652 > Fax: +39 0332 78 6325 > mailto:simon.cox@jrc.ec.europa.eu > http://ies.jrc.ec.europa.eu/simon-cox > > SDI Unit: http://sdi.jrc.ec.europa.eu/ > IES Institute: http://ies.jrc.ec.europa.eu/ > JRC: http://www.jrc.ec.europa.eu/ > -------------------------------------------------------- > > Any opinions expressed are personal unless otherwise indicated. > > -----Original Message----- > From: public-esw-thes-request@w3.org [mailto:public-esw-thes-request@w3.org] > On Behalf Of Leo Sauermann > Sent: Thursday, 10 June 2010 18:41 > To: Simon Cox > Cc: 'Alistair Miles'; public-esw-thes@w3.org > Subject: Re: URIs for Concept & ConceptScheme - best practice? > > It was Simon Cox who said at the right time 09.06.2010 16:55 the following > words: > >> If I'm reading this right, there is a possible tension between >> CoolURIs and REST constraints, right? >> >> > no, read the doc and check it, AFAIK there is not a tension here. > the "CoolURIs for the semantic web" doc explains either # or /, either > conneg or not, and gives hints what to do for which case. > http://www.w3.org/TR/cooluris/ > > Alistair is right in assuming something like 301, but I think pushing this > down only to the HTTP layer is coming from a technocratic perspective. > after all, taxonomies are managed by organizations and published in a > process, so usually you have a big event of publishing changes or updates, > and the users will usually get informed about big changes (and only > organizations who do this tamtam when doing changes are interesting for most > uses, hint: W3C does a lot of process before publishing anything) > > note also that thid discussion does really ignore the experience from XTM, > although maybe not important now and here, XTM has a much longer prove of > the "ability to deliver" than SKOS. > > as you may know, the XTM identifiers are XLinks (ha, another standard) and > look somehow http://www.example.com/schemas/caribbeanislands_0_9.xtm#tortuga > > If I were in the position to publish anything that is used by more people > than my immediate buddies, (and I am somehow in this positoin in oscaf.org), > I would definitly follow what has been working for years in XTM and is also > quite CoolUri compatible and also looks quite intuitive for me. > > Note that updates/version changes/etc are always PITA, but look at how > common taxonomy publishers (like wordnet) handle versioning and try to copy > EXACTLY their approach, or find someone else as long-living as taxonomy > publishers and copy their ways. > (again, pragmatic view from my side: do not take any risk here) > > Afaik Richard (another author of "Cool URIs for the semantic web) likes # > uris a lot recently. > > best > Leo > > > >> Simon >> >> -----Original Message----- >> From: public-esw-thes-request@w3.org >> [mailto:public-esw-thes-request@w3.org] >> On Behalf Of Alistair Miles >> Sent: 09 June 2010 16:08 >> To: public-esw-thes@w3.org >> Subject: Re: URIs for Concept & ConceptScheme - best practice? >> >> Thinking about this again, I think if I had the choice I would avoid >> construction of a concept URI using some token representing the >> scheme, although in some circumstances I still think this would be a >> reasonable thing to do. I think I would instead choose some common >> namespace for all URIs I want to coin under my authority, regardless >> of whether I was coining URIs for one scheme or 20. >> >> E.g., I would do... >> >> http://id.mydomain.com/abcd-efgh-ijkl >> http://id.mydomain.com/mnop-qrst-uvwx >> etc. >> >> My reasoning is that (1) I can imagine you might want to refactor 2 or >> more schemes at some point in time, which might involve moving >> concepts from one scheme to another, but don't want to have to coin a >> new URI for moved concepts (and so break links), and (2) I've been >> trying to swallow the *whole* REST pill lately, which means HATEOAS, >> which means (link templates aside) that you shouldn't write any code >> that makes assumptions about URI structure. >> >> Actually, making these two points next to each other gives me another >> thought, which is that, if you took the REST/HATEOAS view, we really >> shouldn't worry about renaming things, because the web gives you a way >> to manage changes in naming via redirect response codes, most usefully >> 301 Moved Permanently (if I remember my status codes right, sorry am >> writing this offline.) >> >> OK, so I think I will change my opinion: (1) use absolutely any URI >> you like, feel free to build path segments out of the full concept >> hierarchy, or whatever, and (2) make sure any code you write respects >> REST constraints, in particular the hypermedia constraint (HATEOAS), >> so i.e. you're code *never* depends on out-of-band information about >> how the URIs where constructed, and follows links and redirects. >> >> If I'm being pragmatic, I'd probably still go with the proposal at the >> top of this email, but only because it doesn't even give people the >> opportunity of breaking the hypermedia constraint. >> >> Sorry for the mid-email change of tack, but 6 months of lurking on the >> rest-discuss yahoo group is changing the way I think about semweb and >> linked data :) >> >> Cheers >> >> Alistair >> >> >> On Tue, May 18, 2010 at 02:07:00PM +0100, Rob Tice wrote: >> >> >>> I would endorse Antoine's comment. >>> >>> 'And of course any cool URI tricks should not replace proper >>> >>> >> representation >> >> >>> of knowledge about the resources!' >>> >>> In addition (to follow up on Mike's point): >>> >>> The process of developing ontologies/schemes etc and releasing to the >>> >>> >> world >> >> >>> (or maybe assigning URI's) when finished is only one possible approach. >>> >>> When the actual development/evolution of the concepts, schemes and >>> hierarchies also has to be shared and public (even if this is only >>> public within an organisation), assigning URI's based on structure >>> just doesn't work well. >>> >>> Cheers >>> >>> Rob >>> >>> >>> >>> >>> -----Original Message----- >>> From: public-esw-thes-request@w3.org >>> >>> >> [mailto:public-esw-thes-request@w3.org] >> >> >>> On Behalf Of Antoine Isaac >>> Sent: 18 May 2010 11:29 >>> To: public-esw-thes@w3.org >>> Subject: Re: URIs for Concept & ConceptScheme - best practice? >>> >>> Hi everyone, >>> >>> >>> >>>> On Fri, May 14, 2010 at 02:41:39PM +0200, Simon Cox wrote: >>>> >>>> >>>>> I'm thinking about identifier policies for ontologies and >>>>> >>>>> >>> concept-schemes. >>> >>> >>>>> In work that I have done previously on identifier policies for Open >>>>> Geospatial Consortium and for Commission for Geoscience Information >>>>> we >>>>> >>>>> >>> used >>> >>> >>>>> the identifier scheme largely as a way to enforce certain >>>>> governance arrangements for resource publication. The general >>>>> principle is that a >>>>> >>>>> >>> URI >>> >>> >>>>> is composed of a number of fields. A new URI can only be minted if >>>>> the values in all the fields are valid; the allowable value for >>>>> each field >>>>> >>>>> >>> must >>> >>> >>>>> come from a specific register; and different parties are authorized >>>>> to modify different registers. So we end up with a delegation >>>>> system. This >>>>> >>>>> >>> kind >>> >>> >>>>> of scheme uses the URI structure for internal governance purposes, >>>>> >>>>> >> within >> >> >>>>> the community. >>>>> >>>>> But http URIs have a 'path-like' structure which can be interpreted >>>>> as >>>>> >>>>> >> a >> >> >>>>> tree. Read in this way, the URI scheme impies certain relationships >>>>> >>>>> >>> between >>> >>> >>>>> resources, in particular 'ownership' of children by their parents. >>>>> Notwithstanding the REST principle that information is in the >>>>> >>>>> >>> representation >>> >>> >>>>> and not the identifier, Cool URIs can be interpreted by users, and >>>>> >>>>> >>> typically >>> >>> >>>>> support navigation through tweaking the URI (many refs). This kind >>>>> of scheme is aimed at external users. >>>>> >>>>> Following this approach: is it smart to have the URI for a SKOS >>>>> concept >>>>> >>>>> >>> to >>> >>> >>>>> be just an extension of the URI for the SKOS concept scheme? >>>>> >>>>> e.g. >>>>> <http://resource.geosciml.org/concept/ >>>>> <http://resource.geosciml.org/concept/unit-rank/bed> >>>>> unit-rank/bed> skos:inScheme<http://resource.geosciml.org/concept/ >>>>> <http://resource.geosciml.org/concept/unit-rank> unit-rank>. >>>>> >>>>> I'm assuming slash URIs, since I want the server to do most of the >>>>> >>>>> >> work, >> >> >>>>> supporting content-negotiation, etc. >>>>> The advantage in this approach is that a casual user can navigate >>>>> >>>>> >> between >> >> >>>>> parent and child by URI twiddling. >>>>> But possible gotchas are >>>>> (1) it assumes exactly one parent >>>>> - it requires every concept to be in a scheme >>>>> - it privileges one scheme above any others (though I think >>>>> there >>>>> >>>>> >> is >> >> >>> no >>> >>> >>>>> limit on the number of inScheme properties a Concept can have?) >>>>> (2) there must be some others >>>>> >>>>> >>>> I don't see any problem with this, as long as the scheme is the >>>> definitive (i.e., authoritative) scheme for that concept. >>>> >>>> Slightly tangential, but you might also be interested in: >>>> >>>> http://www.cabinetoffice.gov.uk/media/308995/public_sector_uri.pdf >>>> http://www.ivoa.net/Documents/latest/Vocabularies.html >>>> >>>> >>> Very good guidelines, indeed! >>> >>> About Simon's questions. >>> +1 for Alistair and Johan's comments on using some concept scheme "label" >>> >>> >> in >> >> >>> the path for for the concepts that they originally coined. >>> And I would advise against using the parent concepts in the path, >>> unless your scheme has a strict tree structure. Otherwise you'll have >>> to make >>> >>> >> some >> >> >>> hard choices at some places... >>> >>> And of course any cool URI tricks should not replace proper >>> representation of knowledge about the resources! As Rob has pointed >>> out, the data for >>> >>> >> some >> >> >>> resources may change, making obsolete even the best patterns of the >>> moment... >>> >>> Cheers, >>> >>> Antoine >>> >>> >>> >>> >>>>> I'd be interested in comments. >>>>> >>>>> >>>>> -------------------------------------------------------- >>>>> Simon Cox >>>>> >>>>> European Commission, Joint Research Centre Institute for >>>>> Environment and Sustainability Spatial Data Infrastructures Unit, >>>>> TP 262 Via E. Fermi, 2749, I-21027 Ispra (VA), Italy >>>>> Tel: +39 0332 78 3652 >>>>> Fax: +39 0332 78 6325 >>>>> <mailto:simon.cox@jrc.ec.europa.eu> >>>>> >>>>> >> mailto:simon.cox@jrc.ec.europa.eu >> >> >>>>> <http://ies.jrc.ec.europa.eu/simon-cox> >>>>> http://ies.jrc.ec.europa.eu/simon-cox >>>>> >>>>> SDI Unit:<http://sdi.jrc.ec.europa.eu/> >>>>> http://sdi.jrc.ec.europa.eu/ IES >>>>> Institute:<http://ies.jrc.ec.europa.eu/> >>>>> >>>>> >>> http://ies.jrc.ec.europa.eu/ >>> >>> >>>>> JRC:<http://www.jrc.ec.europa.eu/> http://www.jrc.ec.europa.eu/ >>>>> >>>>> -------------------------------------------------------- >>>>> >>>>> >>>>> >>>>> Any opinions expressed are personal unless otherwise indicated. >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > -- > Leo Sauermann, Dr. > CEO and Founder > > mail: leo.sauermann@gnowsis.com > mobile: +43 6991 gnowsis > http://www.gnowsis.com > > helping people remember, > > so join our newsletter > http://www.gnowsis.com/about/content/newsletter > ____________________________________________________ > > > > -- Leo Sauermann, Dr. CEO and Founder mail: leo.sauermann@gnowsis.com mobile: +43 6991 gnowsis http://www.gnowsis.com helping people remember, so join our newsletter http://www.gnowsis.com/about/content/newsletter ____________________________________________________
Received on Saturday, 12 June 2010 14:13:53 UTC