- From: Phil Archer <phil@philarcher.org>
- Date: Tue, 06 Apr 2010 16:22:16 +0100
- To: Michael Hausenblas <michael.hausenblas@deri.org>
- CC: Niklas Lindström <lindstream@gmail.com>, Kingsley Idehen <kidehen@openlinksw.com>, nathan@webr3.org, Danny Ayers <danny.ayers@gmail.com>, Linked Data community <public-lod@w3.org>
Hi all, Thanks for keeping me in this loop and apologies for radio silence thus far. On a theoretical level - making the link registry available as data is, clearly, a jolly good idea and should happen. On a practical level I am sorry to say I don't think I can help. In the e-mail that Michael sent to bring me in to this discussion he said that I was an editor of the Atom registry. Sorry, no, I'm not. The ATOM Link registry is under the control of the IESG [1]. To get 'describedby' in there I had to send an e-mail to IANA [2]. But... it's all meant to be temporary. Version 09 of Mark Nottingham's HTTP Link header Internet Draft has just been published and, if, as we've been hoping for longer than I can remember, it becomes a full RFC then the ATOM Link registry will be replaced by a new registry [3]. The current XML version of the registry has a bunch of declarations that suggest that IANA is open to making different versions available if they can be automated. An XSLT that produced triples would be pretty simple I guess (linked GRDDL-style?) The informal place to raise issues around MNot's draft is the HTTP WG's mailing list (see announcement at [4]). Mark may be open to persuasion on seeking a data version of the registry. Alternatively one could write directly to IANA. Sorry I can't be of more direct practical help. Phil. [1] http://www.ietf.org/iesg/ [2] http://lists.w3.org/Archives/Public/public-powderwg/2009Feb/0007.html [3] http://tools.ietf.org/html/draft-nottingham-http-link-header-09 [4] http://lists.w3.org/Archives/Public/ietf-http-wg/2010AprJun/0014.html Niklas Lindström wrote: > Kingsley, > > 2010/4/6 Kingsley Idehen <kidehen@openlinksw.com>: >> Niklas Lindström wrote: >>>> Niklas, >>>> >>>> Nice! >>>> >>>> I would once again suggest adding local "owl:equivalentProperty" >>>> assertions >>>> which enables a reasoner to treat the IANA URIs as synonyms. This is in >>>> line >>>> with what I like to call the: owl:shameAs pattern :-) >>>> >>>> Kingsley >>>> >>> Hi Kingsley, >>> >>> thanks! >>> >>> Yes, I think that'd be good. But my sketch already describes the IANA >>> URI:s directly (by, unsolicitedly, using >>> @xml:base="http://www.iana.org/assignments/relation/"), so *if* that >>> RDF (or preferably Michael's richer and RDFa-based one) were official, >>> we wouldn't need that, right? (As those would be self-referential >>> statements..) >>> >>> Otherwise, if we were to mint our own ("community official") URI:s for >>> each of these properties, I'd agree that owl:equivalentProperty should >>> definitely be there.. >>> >>> .. Well, unless it would be decided in the future that values in >>> @rel:s at least in Atom are to be viewed as *indirect* references to >>> relations via a document (akin to e.g. foaf:interest). Of course, >>> that's not the case in XHTML+RDFa, but for the default names in @rel:s >>> there the IANA URI:s aren't used (we have the >>> <http://www.w3.org/1999/xhtml/vocab#>-based ones instead). >>> >>> So to nail down the definitions of (the nature of) the things the IANA >>> relation URI:s identify, we'd either have to make it clear that they >>> *are* relations (i.e. properties) in the RDF sense (and >>> object-properties in the OWL sense), or that they're not. If it's >>> undefined, we still can't really make any statements about what they >>> are, even if we make up our own properties based on how we view them. >>> (Well maybe, if it was declared that their precise meaning will be >>> "perpetually undefined".) >>> >>> So if they (the URI:s) are (direct references to relations), it'd be >>> wonderful to have IANA publish some kind of RDF discoverable via [1] >>> to make that clear. >>> >> Thing is that we need RDF data representation now, and if we put the linked >> data somewhere (some data space) ASAP we can point to what will someday >> exist in an IANA data space -- the "shameAs" pattern is a productive >> mechanism for letting folks like IANA understand why this is so important >> etc. :-) > > absolutely. But do you think we should describe and use the IANA URI:s > directly as properties, or that we need to mint new URI:s for them? > The location of the document(s) containing these descriptions may very > well be unreachable from iana.org for now (albeit less than ideal), > but if we need to mint new ones, we cannot really say the iana.org > ones are properties, right*? Since if they are, we should just use > them.. > >> Got to be fast :-) > > True. And durable. ;) > > Best regards, > Niklas > > [*] = Excluding owl:equivalentProperty as well since it's range is > rdf:Property (via rdfs:subPropertyOf). > > >>> [1]: http://www.iana.org/assignments/relation/* >>> >>> >> >> -- >> >> Regards, >> >> Kingsley Idehen President & CEO OpenLink Software Web: >> http://www.openlinksw.com >> Weblog: http://www.openlinksw.com/blog/~kidehen >> Twitter/Identi.ca: kidehen >> >> > -- Phil Archer http://philarcher.org/ +44 (0)1473 434770 i-sieve Technologies | W3C Sentiment Analysis Beyond Impressions | Open Media Web http://i-sieve.com | http://www.w3.org
Received on Tuesday, 6 April 2010 15:22:57 UTC