[Nepomuk] Re: Some (a lot of) ideas for/issues with the Nepomuk ontologies

[Sebastian Trüg]

Hi Leo,

thanks a lot for your comments.

On 06/15/2011 01:25 PM, Leo Sauermann wrote:
>> before creating tons of tickets for SDO I would like to discuss some of
>> the issues I see with the ontologies. So here goes. Please comment.
>>
>> * Would it make sense to create "nco:hasContactMedium
>>   rdfs:subPropertyOf nie:hasLogicalPart" (in that case
>>   nco:ContactMedium would have to be made a nie:InformationElement.).
>>   The alternative is nao:hasSubResource. But how are the two properties
>>   related?
> 
> I tried to clear this up in ticket:
> https://sourceforge.net/apps/trac/oscaf/ticket/98

Just to be clear: you vote for making nco:hasContactMedium a
sub-property of nao:hasSubResource? After all a contact medium without
contact can exist but it fairly pointless.

>> * Should nie:hasPart and nie:hasLogicalPart be subproperties of
>>   nao:hasSubResource?
> nie:hasPart: according to the proposed new definition (see above), the
> nco:containsContact and ncal:component, ncal:attach properties would not
> allow nie:hasPart to be a subpropetry of nao:hasSubResource.
> subresources should only be used in parts that can't "live" without
> their super. for example, address details inside an nco Contact.

OK, what about nie:hasLogicalPart?

>> * Should we not use nfo:Website as range for a property like
>>   nco:websiteUrl
>>
>> * nie:created should NOT be a sub property of nao:created. The latter
>>   refers to the RDF resource while the former refers to the DataObject
>>
>> * Should we deprecate ncal:comment in favor of nie:comment?
> The property as such has a small reason to be as a subproperty of
> nie:comment because it makes it easier to parse/serialize between
> RFC2445 and between NCAL.
> I would propose to interpret, when reading data, a nie:comment as
> ncal:comment if no ncal:comment is given, and when writing data to write
> ncal:comment.
> (does this sound like a good idea?)
> I would propose to subproperty them.

Agreed: ticket: https://sourceforge.net/apps/trac/oscaf/ticket/101

>> * Why is ncal:cutype not expressed via actual rdf types?
> because then the range of ncal:cutype would be rdfs:Class and that would
> really suck. because you wouldn't know what values would fit.

Actually what I meant was to make them sub-classes to nco:Attendee.

> (and making the class a subclass of rdfs:class is calling for trouble
> because suddenly they will only be rdfs:Classes if "inference=on" and
> then .... chaos! also having them as instances makes it easy to i18n them)
> The types are defined here, for example:
> https://sourceforge.net/apps/trac/oscaf/browser/trunk/ontologies/ncal/ncal.trig#L1311
> 
> 
> 
>> * in what relation does ncal:attachmentUrl stand to nie:url? Is it
>>   required at all?
>>
>> * ncal:timestamp seems redundant when we have nie:contentCreated.
>>   Should we make it a subproperty and deprecate it?
>>
>> * Maybe we even need fixed cardinality of 1 for the ncal:NCalDateTime
>>   properties
>>
>> * nco:imStatus has a string range. That is just awful. Especially since
>>   there is also nco:imStatusMessage which can be used to store an
>>   arbitrary message. nco:imStatus should have a resource range with a
>>   dedicated nco:ImStatus type and predefined instances.
>>
>> * nao:creator like the other nao properties should refer to the creator
>>   of the resource itself (in the database) as compared to the creator
>>   of the content (of a nie:informationElement or nie:DataObject). This
>>   includes files. Thus, properties like nco:creator should NOT be
>>   sub-properties of nao:creator.
>>
>> * We need a property to state who created the content of a
>>   nie:InformationElement. We have nco:creator but it refers to
>>   DataObjects.
> actually, I think thats an error in the rdfs:comment.
> The domain is nie:InformationElement, and reading the sub-properteies
> ("nexif:artist") it is obvious that it means the creator of the
> infomration element, and not the data object. So I propose to change the
> comment:
> https://sourceforge.net/apps/trac/oscaf/ticket/99

ok, great.

>> * nfo:Website: I think it should be a nie:DataObject. The comment
>>   states that it can be interpreted as a HTMLDocument and it does not
>>   make any sense to interpret a IE as IE.
> Good one. don't know. Would depend on the examples how its used so far.

So far they are mostly only used as-is, ie. a website is a website and
nothing else, no additional DO type. I suppose that it would be more
correct to let a website be a nfo:Website and a nfo:HTMLDocument or
something like that (if we changed nfo:Website to be a DO instead of an IE).
In some cases they are a nfo:RemoteDataObject in addition to that. This
makes sense but bears the question whether nfo:Website should be
subclass to nfo:RemoteDataObject or if web sites can also be local? Is a
local website still a website or it is just a site then?

Cheers,
Sebastian