[foaf-dev] Re: updated FOAF spec

[Dan Brickley]

Henry Story wrote:
> By the way, thanks for the excellent work. It is really helpful to have 
> the content negotiation on terms work again, when explaining the 
> semantic web to people. The html page looks a lot better too.

Thanks. Work in progress...

> An interesting point against vocabularies that don't use the #term btw I 
> noticed now is that it does not make it possible for a click on a term 
> such as http://xmlns.com/foaf/0.1/knows to redirect to 
> http://xmlns.com/foaf/spec/#term_knows (or am I wrong?).

I tried including the #etcetc bit in the Apache config once, and found 
it was escaped in the HTTP response that was sent, making it useless. 
The only other idea I can think of is to put a bit of .js in the spec 
that checks the HTTP REFERER (if indeed the original URL is considered 
the referer). Would that be icky or useful? And what should the .js 
exactly do?

> The SPARQL example idea sounds good.
> 
> I was thinking another interesting thing to do would be to work out how 
> to do unit testing of vocabularies and conjunction of vocabularies with 
> other vocabularies.  Ontologies should perhaps only use the owl:import 
> on ontologies they have done a full bunch of unit tests with. (So one 
> should probably never import wordnet). Then a vocabulary could specify 
> the other ontologies it had been tested with. That would help guide one 
> a little.
 >
> Tests could include things like: merging those vocabularies won't lead 
> to empty classes, no contradictions, ... (what more?).
> One could specify that the vocabularies were tested up to depth n... or 
> something.

Definitely worth exploring. I think Pellet and other OWL tools might 
have something to offer here...

Dan


> Henry
> 
> On 29 May 2007, at 04:24, Dan Brickley wrote:
> 
>>
>>> btw, one thing that I sometimes find missing when reading a spec is 
>>> some guidance as to which other ontologies play nicely with a given 
>>> one. Some ontologies are so minimal it feels like there are a number 
>>> of missing properties until one realises that one is meant to use a 
>>> dc property for example.
>>
>> Yes, ... exactly! Sometimes "finding another way to express yourself" 
>> may mean using an alternate namespace/vocab instead. There are many 
>> areas that straddle vocabs. Topics are currently a good example; SIOC 
>> is stabilising and has its own sioc:topic, there is SKOS, and 
>> dc:subject ... and discussions in SKOS scene about how to relate 
>> between a thing described as a topic (eg. the topic of Paris) and the 
>> "thing itself" (ie. the City). Geography is another one.
>>
>> On the SemWeb, describing things in detail will very often involve 
>> combining namespaces. And there are no solid conventions for doing so. 
>> The Dublin Core community calls these combinations "application 
>> profiles" btw. I have some draft ideas floating around from those 
>> discussions I should dig out and post. One thought I keep coming back 
>> to is the use of a SPARQL query directory (even just a wiki) that 
>> keeps some common multi-namespace patterns in a form that allows them 
>> to be cited, linked, annotated etc. This appeals to me as a technique 
>> that might bridge from human-oriented use cases ("I want to find 
>> opening hours of shops that sell XYZ in Bristol, and their telephone 
>> number", "I want to find people interested in Iraq, who are qualified 
>> as a journalist, and have been there", "I want to find free software 
>> that can read this file format" ...) ... with machine-oriented 
>> formats. In practice I think a SPARQL directory would have *lots* of 
>> queries, rather than one per "application profile", since requirements 
>> vary slightly all the time, as do the contents of data-sets. My 
>> original thinking was that a single or handful of such queries could 
>> capture each "combination" of namespaces, but I now think that a 
>> little unrealistic.
>>
>> What I'd like to do to explore this further, ... is migrate the FOAF 
>> wiki to use openID and (semantic)mediawiki, ... restrict edits to 
>> people logging in via openID, ... and make a SPARQL query directory 
>> prototype on top of that as a light-ish-weight platform. Plausible?
>