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

[Sebastian Trüg]

Hi Andrew,

On 04/04/2011 07:48 PM, Andrew Lake wrote:
> Sebastian Trüg" wrote:
>> Hi guys,
>>
>> 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?
>>
>> * Should nie:hasPart and nie:hasLogicalPart be subproperties of
>>  nao:hasSubResource?
> 
> Makes sense to me.+1

I think so, too. But maybe we should run some examples to see if it
really matches all use cases.
The interesting thing here is that with the upcoming data management
service Nepomuk automatically deletes sub-resources if they are no
referenced by anything else.

>>
>> * Should we not use nfo:Website as range for a property like
>>  nco:websiteUrl
> 
> I hesitated on this one since it seems like nco:website might have
> been a better property, but not a big deal. +1

We could simply introduce nco:website and deprecate nco:websiteUrl. That
would even keep backwards compatibility.

>>
>> * 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
> 
> +1
> 
>> * 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.
> 
> Makes sense to me. +1
> 
>>
>> * We need a property to state who created the content of a
>>  nie:InformationElement. We have nco:creator but it refers to
>>  DataObjects.
> 
> In version 0.6 of SDO, I notice that the domain of nco:creator is
> actually nie:InformationElement not nie:DataObject even though the
> rdfs:comment says "Creator of the data object".
> 
> I almost wish we could just have multiple domains for this property
> (or just set the domain to rdfs:Resource) and let the data provide the
> semantics:
>  - nie:InformationElement is the content/work/interpretation (e.g. song)
>  - nie:DataObject is an instance/representation of the
> content/work/interpretation (nie:InformationElement) (e.g. the MP3
> file)
>  - If nco:creator is a property of a nie:InformationElement resource
> then the creator is of the content/work/interpretation. (e.g. creator
> of the song)
>  - If nco:creator is a property of a nie:DataObject resource then the
> creator is of the instance/representation of the
> content/work/interpretation. (e.g. creator of the MP3 file)
> 
> Of course, the problem is if the resource is set to be both an
> nie:InformationElement and nie:DataObject.  However, I assume that
> shouldn't happen if we're properly maintaining
> interpretation/representation separation using nie:InformationElement
> nie:hasPart nie:DataObject and nie:DataObject nie:isPartOf
> nie:InformationElement.

Actually for files we always use the same resource for IE and DO. I
think this is even mentioned in the NIE documentation.
Thus, we sadly cannot use the same property for both which means that we
need an additional property like nie:contentCreator and adjust the
domain of nco:creator to match the documentation.

Cheers,
Sebastian