Re: RDF vocabulary scope guidelines, promoting properties to classes - property identifiers

Jiri,

Stefano and I had a good conversation about this.

In a world where the RDF model is extended to allow meta-annotations  
-- i.e., John says X at time Y on server Z... -- then something like  
the tag ontology is completely unnecessary. Just say "x tag y" and let  
the meta-metadata sort the rest out.

However, we cannot do that in RDF as standardized. As a result,  
hundreds of domain ontologies are doomed to do exactly what the tag  
ontology does: reify a domain object and place annotations on it. "RDF  
reification" (the vocabulary for describing triples) is not a  
solution, because it does not assert the reified statement. Named  
graphs also don't do the trick: firstly it's not quite standard RDF,  
but secondly you would sometimes need one graph per triple -- no good.

In AllegroGraph we experimented with first-class triples: a triple ID  
can be used like any resource. I regard this with some skepticism,  
because it's rather incompatible with SPARQL and RDF serialization  
formats, and is fragile (e.g., breaking when you transfer the data  
elsewhere).

In short: there is no good implementation-independent way to avoid  
ontologies stuffed full of reification.

--
Sent from my iPhone.

On Feb 7, 2009, at 5:34, Jiri Prochazka <ojirio@gmail.com> wrote:

> Hi Richard,
>
> Richard Newman wrote:
>> Hi Jiri,
>>
>> As the author of that ontology, I am in the unique position of being
>> able to explain my modelling choices!
>>
>> I took that approach for two reasons:
>>
>> 1: precision. By creating my own term, I can define precisely what is
>> meant by (for example) "creation" -- is it the moment I choose to  
>> add a
>> tag, or the time that tag reached some server? Another way of  
>> phrasing
>> this is that coining a new property or class allows for "minimal
>> enforced ambiguity".
>
> You've got a point there, I agree vocabularies should define their  
> terms
> but also link (use sub-class, sub-property) to other (more general)
> vocabularies. Current weak deployment of inferencing should not affect
> the design of data.
>
> However I think my original problem was about something else - Tagging
> is a property promoted to class... this is because you want to express
> more information about the relation between two objects, more than  
> that
> it just exists.
> Now, what if someone wanted to promote for example foaf:knows to a
> class, adding information about when the people got the know each  
> other?
> That is quite realistic... or how long they know each other...
> He could promote foaf:knows to class ("Knowing"? :), but that would  
> make
> chaos in current data which use normal property foaf:knows...
> The problem is, that in RDF individual uses of properties (ie triples)
> cannot be identified (by default).
> There are named graphs and reification, but they seem too ugly to me.
> Is there any elegant way to solve this? How to do relation description
> in RDF properly?
>
> Best regards,
> Jiri
>
> (forgot to CC to semantic-web@w3.org)
>
>>
>> 2: a related point: by deliberately using a new term, it can be
>> specifically and accurately related to other terms in other  
>> ontologies
>> -- e.g., my taggedOn might be an equivalentProperty to John Smith's
>> tagdate, and a subproperty of a generic date property. Under  
>> inference,
>> all desired knowledge is apparent, without being corralled into a
>> not-quite-compatible ontological framework.
>>
>> The expense of reasoning is a slight discouragement to this approach,
>> but I think in general it stands up.
>>
>> HTH,
>> -Richard
>>
>>
>> -- 
>> Sent from my iPhone.
>>
>> On Feb 6, 2009, at 15:24, Jiri Prochazka <ojirio@gmail.com> wrote:
>>
>>> Hi,
>>> I am sure I am not the first one to notice, but I think there is a
>>> problem with determining scope when designing a RDF vocabulary.  
>>> Reuse of
>>> well designed, loosely coupled, high cohesion, more general  
>>> vocabularies
>>> versus domain specific vocabularies.
>>>
>>> Typical example is date of creation. I am writing this largely  
>>> thanks to
>>> this vocabulary: http://www.holygoat.co.uk/projects/tags/
>>> It defines class Tagging, which uses properties taggedBy and  
>>> taggedOn.
>>> This is the domain specific approach. The example is:
>>> <http://example.com/blog/post/1> :tag
>>>   [ a :Tagging ;
>>>     :associatedTag tag:blog, tag:chimpanzee ;
>>>     :taggedBy <http://example.com/People/Jim> ;
>>>     :taggedOn "2005-03-29T15:24:10Z"^^xsd:date ] .
>>>   tag:blog :tagName "blog" .
>>>   tag:chimpanzee :tagName "chimpanzee" .
>>>
>>> But as another alternative I imagine:
>>> { <http://example.com/blog/post/1> :tag tag:blog, tag:chimpanzee . }
>>>   time_vocab:createdOn "2005-03-29T15:24:10Z"^^xsd:date ;
>>>   author_vocab:author <http://example.com/People/Jim> .
>>> tag:blog :tagName "blog" .
>>> tag:chimpanzee :tagName "chimpanzee" .
>>>
>>> Where time_vocab and author_vocab talk about RDF resources (graphs  
>>> in
>>> fact) and could be defined in just one RDF resource description
>>> vocabulary instead of two.
>>> Or another alternative in which time_vocab:createdOn and
>>> author_vocab:author have domain rdfs:Class:
>>> <http://example.com/blog/post/1> :tag tag:blog, tag:chimpanzee ;
>>>   time_vocab:createdOn "2005-03-29T15:24:10Z"^^xsd:date ;
>>>   author_vocab:author <http://example.com/People/Jim> .
>>> tag:blog :tagName "blog" .
>>> tag:chimpanzee :tagName "chimpanzee" .
>>>
>>> Which of this approaches is recommended and why?
>>>
>>> I tend to agree more with the more general vocabulary approach.  
>>> Like you
>>> should ask yourself when designing RDF properties "Shouldn't the
>>> domain/range of it be some parent class? If yes, does the property  
>>> fit
>>> the scope of this vocabulary? Shouldn't it be in some more general
>>> one?", focusing on reuse rather than rely on later linking of
>>> vocabularies.
>>>
>>> If there were any past discussions on this topic, what were the  
>>> results
>>> of it?
>>> Is there any vocabulary for rating resources in terms of  
>>> authenticity
>>> (trust) and agreement (truthfulness)? Vocabulary(ies) covering other
>>> resource description aspects would be helpful too... (POWDER is so
>>> cumbersome)
>>>
>>> Best regards,
>>> Jiri
>>>
>
>
> <signature.asc>

Received on Saturday, 7 February 2009 18:35:10 UTC