- From: Alan Ruttenberg <alanruttenberg@gmail.com>
- Date: Wed, 18 May 2011 21:08:06 -0400
- To: Ryan Kohl <ryanckohl@gmail.com>
- Cc: "alexpi@gmail.com" <alexpi@gmail.com>, Marco Neumann <marco.neumann@gmail.com>, Michael F Uschold <uschold@gmail.com>, glenn mcdonald <glenn@furia.com>, Martin Hepp <martin.hepp@ebusiness-unibw.org>, "semantic-web@w3.org" <semantic-web@w3.org>, "public-lod@w3.org" <public-lod@w3.org>
On Wed, May 18, 2011 at 8:38 PM, Ryan Kohl <ryanckohl@gmail.com> wrote: > Why stop there - why not posit a rewrite of the RDF, RDFS, and OWL > vocabularies according to this naming protocol: I would if I had control. Where I have control I am - there will be a new version of RO, for example, that does this. > @prefix ro: <http://www.obofoundry.org/ro/ro.owl#> . > @prefix obo: <http://purl.obolibrary.org/obo/> . > obo:IAO_0000104 rdf:IAB00001239 owl:IAC00008872; > rdfs:IAB000012887 > [ rdf:IAB00001239 owl:IAC00002341; > owl:IAC00000042 ro:BBR11774423; > owl:IAC10101010 obo:IAO_00000005 ]. > I can see how this would help ontology efforts aimed at tagging efforts. ? > But for situations where A-BOX querying is central (like most linked data > scenarios), these meaningless URIs just get in the way. In the OBO id policy document I've listed what I consider gets in the way of using meaningful ids. I see exactly two problems with using "meaningless" ids, both of which I consider to be symptoms of short-sightedness or lack of imagination or lack of appreciation of computer science. 1) SPARQL has to be written in terms of ids only. Why isn't there the ability to import modules? Why isn't there a simple macro system? 2) People want to write machine-directed messages in text editors. There has been much done in computer science to manage abstraction and modularity, none of which has been applied in the SPARQL spec. As far as (2) goes, I don't see many people writing postscript in text editors, yet somehow postscript is a successful language. What should we learn from this? > Remember that many > linked data scenarios will find sparql queries embedded in Java, Python, and > C++ code. It seems a bit much to expect a query writer/developer to > maintain literally unreadable source code. Absolutely. And a little bit of education and mentoring in good software development practices would go a long way in making this not happen. There's no reason why SPARQL (or SQL) should be embedded in computer code. Query text should be considered a resource, in the same way that savvy developers consider natural language strings a resource (and thus enable easy internationalization). Have a look at http://obi.svn.sourceforge.net/viewvc/obi/trunk/src/tools/build/external-templates.txt?revision=3210&view=markup This is how we manage SPARQL in OBI. It lives in a separate file as template and is interpreted by a program, which does substitution. Think ".h" files, or css versus html versus javascript. -Alan > > On Wed, May 18, 2011 at 7:26 PM, Alan Ruttenberg <alanruttenberg@gmail.com> > wrote: >> >> @prefix ro: <http://www.obofoundry.org/ro/ro.owl#> . >> @prefix obo: <http://purl.obolibrary.org/obo/> . >> >> obo:IAO_0000104 rdf:type owl:Class ; >> rdfs:subClassOf >> [ rdf:type owl:Restriction ; >> owl:onProperty ro:has_part ; >> owl:someValuesFrom obo:IAO_0000005 >> ] . >> >> If you can't figure out what this means, ask your favorite LOD browser >> for help, or build a better one. >> >> -Alan >> >> On Wed, May 18, 2011 at 6:49 PM, alexpi@gmail.com <alexpi@gmail.com> >> wrote: >> > >> > za ssw m >> > Sent from my LG phone >> > >> > Marco Neumann <marco.neumann@gmail.com> wrote: >> > >> > >Michael, >> > > >> > >indeed I did not not read Alan's email. I assume he refers to A-Box >> > >identifiers only. >> > > >> > >On Wed, May 18, 2011 at 4:31 PM, Michael F Uschold >> > > <uschold@gmail.com>wrote: >> > > >> > >> On Wed, May 18, 2011 at 1:26 PM, Marco Neumann >> > >> <marco.neumann@gmail.com>wrote: >> > >> >> > >>> Glenn, >> > >>> >> > >>> it's not feasible, nor enforceable, nor desirable to develop >> > >>> ontologies >> > >>> entirely with random URIs as identifiers. >> > >> >> > >> >> > >> *Perhaps you have not seen Alan Ruttenberg's email on this topic. I >> > >> think >> > >> they do exactly this. It was no free lunch, they had a lot of work >> > >> to do to >> > >> make this doable -- in large part because as Glenn says, the duality >> > >> of: >> > >> "machines need to think in ids and people need to think in names" is >> > >> not >> > >> well supported by tools or methodology.* >> > >> >> > >> >> > >>> I am of the opinion that local names should indeed be designed with >> > >>> meaningful names in mind last but not least to improve the ontology >> > >>> engineering process. Though that said there might be exceptions such >> > >>> as NLP >> > >>> and ML where automatic tagging and ontology creation with random >> > >>> URIs can >> > >>> useful, but that's a special use case. >> > >>> >> > >>> Marco >> > >>> >> > >>> >> > >>> On Wed, May 18, 2011 at 3:55 PM, glenn mcdonald <glenn@furia.com> >> > >>> wrote: >> > >>> >> > >>>> I agree wholeheartedly that URIs should be pure identifiers, with >> > >>>> no >> > >>>> embedded semantics or assumptions of readability. And I agree with >> > >>>> Kingsley >> > >>>> that there's an elephant in the room. I might even agree with >> > >>>> Kingsley about >> > >>>> what the elephant is. >> > >>>> >> > >>>> But to say it from my point of view: machines need to think in ids, >> > >>>> people need to think in names. The RDF/SPARQL "stack", such as it >> > >>>> is, has >> > >>>> not internalized the implications of this duality, and thus isn't >> > >>>> really >> > >>>> prepared to support both audiences properly. Almost all the >> > >>>> canonical >> > >>>> examples of RDF and SPARQL avoid this issue by using toy use-cases >> > >>>> with >> > >>>> semi-human-readable URIs, and/or with literals where there ought to >> > >>>> be >> > >>>> nodes. If you try to do a non-trivial dataset the right way, you'll >> > >>>> immediately find that writing the RDF or the SPARQL by hand is >> > >>>> basically >> > >>>> intractable. If you try to produce an human-intelligible >> > >>>> user-interface to >> > >>>> such data, you'll find yourself clinging to rdfs:label for dear >> > >>>> life, and >> > >>>> then falling, falling, falling... >> > >>>> >> > >>>> In fact, there's almost nothing more telling than the fact that >> > >>>> rdfs:label is rdfS! This is in some ways the most fundamental >> > >>>> aspect of >> > >>>> human/computer data-interaction, and RDF itself has essentially >> > >>>> nothing to >> > >>>> say about it. >> > >>>> >> > >>> >> > >>> >> > >>> >> > >>> -- >> > >>> Marco Neumann >> > >>> KONA >> > >>> >> > >>> Make sure to join us at the Semantic Technology Conference 2011 in >> > >>> San >> > >>> Francisco and save 15% with the coupon code STMN >> > >>> http://www.lotico.com/evt/stc2011/ >> > >>> >> > >> >> > >> >> > >> >> > >> -- >> > >> Michael Uschold, PhD >> > >> Senior Ontology Consultant, Semantic Arts >> > >> LinkedIn: http://tr.im/limfu >> > >> Skype, Twitter: UscholdM >> > >> >> > >> >> > > >> > > >> > >-- >> > >Marco Neumann >> > >KONA >> > > >> > >Make sure to join us at the Semantic Technology Conference 2011 in San >> > >Francisco and save 15% with the coupon code STMN >> > >http://www.lotico.com/evt/stc2011/ > >
Received on Thursday, 19 May 2011 01:19:15 UTC