Re: How to avoid that collections "break" relationships (ISSUE-41)

Hi Markus,

> It will always be a trade-off but generally I prefer things that can be
> reused in various scenarios. If possible, we should keep the set of concepts
> as small as possible and reuse them in different scenarios. I think it is
> quite obvious (IMO, anyway) what "manages" means when it appears on a Collection.

Nah, "manages" is really vague. I could think of several other interpretations.

But before deciding on a word, let's maybe think what we mean to say?
What is the predicate supposed to express?

> The advantage of such a generic term is that we could for
> example reuse it to describe other things in the future as well, e.g., on Operations.

Reuse is not necessarily an advantage.
(cfr. rdfs:seeAlso, which can be reused everywhere).

The question we need to ask ourselves is:
what should clients be able to do with this property?

> That's also the reason why I'm
> somewhat hesitant to set manage's domain to Collection.

Maybe it does make sense, depends on what we need.

> As Gregg noted in a different mail [1] (I'm on a plane, so perhaps he
> already responded himself in the meantime) using rdf:subject etc. would mean
> that the whole thing is an rdf:Statement:

Which does not need to be a bad thing.

>  I don't think we want to invoke Reification

But we are: if we say that
"this is the document consisting of triples with that subject and predicate",
we are doing reification. No need to hide that.

> I think these properties are so generic that a domain (at least an
> rdfs:domain) is counterproductive as it inhibits reuse in different scenarios…

Generic is only fine to a certain extent.
We do want machines to derive some value of of the properties.

>> (But still, the blank node needs to be "something", to help us think about it.)
> 
> Good point. But does a machine need it as well?

Maybe not… the spec does, though ;-)

Cheers,

Ruben

Received on Thursday, 5 June 2014 13:35:57 UTC