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

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