[foaf-dev] Re: updated FOAF spec

Phil Archer parcher at icra.org
Wed May 30 10:58:00 BST 2007


I must apologise for complete silence on this discussion so far and 
thank everyone for including me in it.

Obviously, like Shadi, I am most grateful, Dan, for your doing this 
work. Also, the discussion about managing vocabularies, stability etc is 
critical.

Our next POWDER meeting is on Monday and we'll discuss this then. It is 
possible, but by no means certain, that later in the year we'll want to 
come back with further terms we think are useful. For example, sooner or 
later we'll want to work out just what we'd expect to find in a 
foaf:Organization instance. The vCard stuff is obviously important here 
as well but might be the SKOS topics and, quite possibly from FOAF, 
things like fundedBy and theme. Actually we're already planning to use 
skos:relatedConcept to anchor user-generated tags in something with 
better-defined semantics.

Phil.

Dan Brickley wrote:
> Henry Story wrote:
>> Oops sorry. I just realised on reading this thread more closely that 
>> these relations exist in owl:
>>
>> owl:DeprecatedClass and owl:DeprecatedProperty
>>
>> Sorry.
> 
> No worries, we neglected them too in the FOAF scene.
> 
> I increasingly like the metaphor of RDF/OWL vocab as dictionary, and 
> think this worth saying explicitly, to avoid the common default of 
> thinking about these things are file or document formats. That mode of 
> thought makes sense in XML, but with RDF, ... doesn't really. So I think 
> a section of the "dictionary" for words that are ... "deprecated" means 
> something like "if you go using these terms ... well ... here's what 
> they are generally taken to mean ... but there are good reasons for 
> trying to find another way of expressing yourself.". It might be 
> interesting to enumerate (just in prose for now) some of the various 
> reasons for deprecation, and see how the dictionary metaphor shapes up 
> for each. For eg., Deprecated-"archaic", deprecated-"other vocab 
> preferred", deprecated-"duplication", deprecated-"murky semantics", 
> deprecated "nobody liked it or used it", etc.
> 
>> 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?
> 
> Dan
> 
>> Henry
> 



More information about the foaf-dev mailing list