Re: Best Practice for Renaming OWL Vocabulary Elements

Queries as resources isn't a shabby idea.  If the tooling is awesome, then
meaningless T-Box URIs can be an awesome idea for interoperability (I've no
problem at all with meaningless A-Box URIs, and quite prefer them).  That
said, I'd prefer to try the tooling before I changed the data
representation, though.  Otherwise, it'd be difficult to use something like
rrdf <https://github.com/egonw/rrdf> if the URIs in the T-Box were
meaningless - I haven't yet seen anything on the
CRAN<http://cran.r-project.org/> to
write queries in the way you're talking about.
-Ryan

On Wed, May 18, 2011 at 9:08 PM, Alan Ruttenberg
<alanruttenberg@gmail.com>wrote:

> 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/
> >
> >
>