Re: [Dbpedia-discussion] RE : [ISSUE-77] [ISSUE-48] Re: Skos subject properties are deprecated

Richard Cyganiak wrote:
> Antoine,
>
> On 24 Jan 2008, at 18:08, Antoine Isaac wrote:
>   
>> I'm afraid I have to support all these claims, Richard :-)
>> I don't remember the precise reference, but I read once that an  
>> antelope becomes a document as soon as it is in a zoo, which makes  
>> quite some sense to me.
>>
>>     
>
> I love this example! The common sense part of my brain says: “What are  
> these guys smoking?” While the purely logically trained part of my  
> brain says: “Yes, this makes total sense. Obviously an antelope in a  
> zoo is a document.” It's a fascinatingly complicated issue.
>
>   
>> Actually in your wikipedia case there might be a problem anyway. I  
>> would not say that it is the TimBL resource which is about the  
>> history of the net, but its description on wikipedia: what if this  
>> description had been purely biological (size, hair color, preferred  
>> beer)? In this case the categorization of the resource you describe  
>> under "history of the internet" would be problematic, wouldn't it?
>>
>>     
>
> I don't think it would be problematic. I want to put the man into the  
> “history of the net” bucket, not any particular description of him.  
> The description's purpose is just to establish whom we are talking  
> about.
>
> “TimBL is about the history of the net” is a weird statement, I agree  
> with you on that point (and probably disagree with Bernard). But  
> that's part of my argument for a new property: I feel that “A  
> skos:subject B” carries a certain implication, in natural language,  
> that “A is about B”. I would prefer having another property that does  
> not carry that implication.
>
> “A skos:indexedIn B” -- “TimBL is indexed under the concept History of  
> the Net”.
>
>   
>> Cheers, (and thank you all of all for this very interesting  
>> discussion on an important issue for SKOS. For the moment no formal  
>> decision has been taken whether to deprecate skos:subject and to  
>> "replace" it by dc:subject, so any input is welcome)
>>
>>     
>
> Just one more point that hasn't been raised yet in this thread: My  
> subjective feeling is that vocabularies should be well-rounded  
> packages that address all the typical needs of a particular domain.  
> Some duplication with existing vocabularies is acceptable if it makes  
> the new vocabulary more complete. From that point of view, retaining  
> skos:subject is a good idea. Many SKOS users will need it, and SKOS is  
> a much nicer package if it remains included.
>
> (Of course it's still important to declare subclass- and subproperty  
> relationship to existing vocabularies.)
>
> Richard
>
>
>
>   
>> Antoine
>>
>> -------- Message d'origine--------
>> De: public-esw-thes-request@w3.org de la part de Simon Spero
>> Date: jeu. 24/01/2008 18:47
>> À: Richard Cyganiak
>> Cc: Mikael Nilsson; Bernard Vatant; Peter Ansell; dbpedia-discussion@lists.sourceforge.net 
>> ; SKOS
>> Objet : Re: [ISSUE-77] [ISSUE-48] Re: [Dbpedia-discussion] Skos  
>> subject properties are deprecated
>>
>>
>> On Jan 24, 2008, at 10:42 AM, Richard Cyganiak wrote:
>>
>>     
>>> On 24 Jan 2008, at 15:26, Simon Spero wrote:
>>>       
>>>>> Like skos:subject, dcterms:subject seems to be intended for use on
>>>>> documents, not people or cities. Hence it doesn't really meet
>>>>> DBpedia's requirements.
>>>>>           
>>>> The meaning of "document" in this context is extremely broad;  if
>>>> we follow  Otlet's definition of a document as anything which can
>>>> convey information to an observer(Buckland 1997),  the term would
>>>> seem to cover anything which can have a subject.
>>>>
>>>> By this standard, timbl is a document, but only when someone's
>>>> looking.
>>>>         
>>> Sorry, but you lost me there. Where I live, people are not
>>> documents, and I like it here.
>>>       
>> Following Otlet, people aren't documents by virtue of being people;
>> they are only documents if they are carrying conveying some sort of
>> information.  For example, timbl as document can answer the question
>> "what colour is Tim's hair?"
>>
>> Under this framework, it is quite reasonable to say that timbl (the
>> person)  is about "Berners-Lee, Tim."
>>
>> Simon
>>
>>
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Dbpedia-discussion mailing list
> Dbpedia-discussion@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>
>   
Richard,

What abot making a generic association via a properly that carries the 
"Association" or "associatedWith" name and appropriate labeling which 
also carries natural language comprehension benefits?

We are trying to tag but in a formal sense. Tagging is about 
Association, but the association's actual intent lies in the hands of 
the tagger.

A generic property of this nature will mesh with SKOS and MOAT etc..

Through MOAT and Yago we should be able to make DBpedia tag predicates 
(whatever is used for categorization) clearer. This will also kill the 
Person vs Document issue since DBpedia will not implicitly or explicitly 
infer anyting beyond basic Association across Data Objects (resources) 
in the Data Graph.


-- 


Regards,

Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com

Received on Thursday, 24 January 2008 19:26:05 UTC