w3c / dxwg

Data Catalog Vocabulary (DCAT)
https://w3c.github.io/dxwg/dcat/
Other
150 stars 47 forks source link

Replace FOAF terms - Agent #1367

Closed dr-shorthair closed 1 year ago

dr-shorthair commented 3 years ago

DCAT is a bit bogged-down by using some FOAF terms, while even the authors of FOAF have long since moved on to other vocabularies (esp. Schema.org).

AFAICT there are no obvious like-for-like replacements for foaf:homepage and foaf:primaryTopic.

But it would be a trivial to replace foaf:Agent with dcterms:Agent. I can't actually imagine what problems it could cause - @makxdekkers @andrea-perego?? It is only pointed to by dcterms:creator and dcterms:publisher so it would at least be more consistent with DCMI to use the DC class instead of reaching sideways into another vocabulary of dubious quality and governance.

makxdekkers commented 3 years ago

I don't see a problem with referring to dcterms:Agent instead of foaf:Agent. In the namespace document of FOAF, foaf:Agent is declared to be owl:equivalentClass of dcterms:Agent.

danbri commented 3 years ago

(Since this thread is still being routed by intelligent github agents into my inbox, and from there by other gmail agents, into my apple ios phone, and from there by pixel agents into my eyes, I feel compelled to comment)

The FOAF maintainers, still being broadly of sound body and mind, have a mostly annual check-in with Tom Baker of DCMI, who has (or have, since Tom acts for DCMI in this capacity) been given access to the relevant DNS accounts at Gandi.net. Neither FOAF nor DCMI are changing much lately, but care is taken to maintain them both as widely used vocabularies.

https://www.dublincore.org/collaborations/foaf/DCMI_FOAF_Cooperation/DCMI_FOAF_Agreement/ (Makx is still listed as a signatory- maybe we should update that?)). I still stand by the commitments made there..

BTW to celebrate Schema.org’s 10th birthday I want at least to update FOAF’s terms like Person for consistency with Schema.org (and tweaks in the other direction too if need be), including equivalence statements.

Looking at the specific vocabulary described here, I am not sure whether the concept of a “homepage” is a relic of a bygone era, but the actual meaning of this type “Agent” is INCREDIBLY vague, whether in the high quality and respectably governed Dublin Core terms, or in the dubiously governed and notoriously sketchy so-called FOAF namespace.

I would gently encourage you to concern yourselves more with what you’re trying to say than with which URI to use when saying almost nothing.

Looking at the two definitions of “Agent”:

“ A resource that acts or has the power to act.” (DCMI)

“ things that do stuff.” (FOAF)

Both of these are, deep down, fundamentally linguistic rather than intrinsic; they appeal to our inclination to describe situations using sentences driven by verbs.

Who or what cleaned the carpet? Was it me, or Elsie, my roomba vacuum cleaner? Who published that manifesto, was it Karl the communist Person, or his shadowy Organization?

Who or what broke the greenhouse window, was it Alice, the kid next door, or that meteorite that fell from the sky?

Who created that huge Apache httpd log file? The running software, the “admin” unix user account, or Bess the sysadmin? Who accidentally published it? etc...

Who deleted all my files? Was it an early version of Google Drive, after I tidied up some aliases on my desktop, or was it me, for not reading the documentation on whether aliases and symbolic links are followed deeply when “empty trash” is clicked? Or was it the Operating System “agent”? Or the situation? Only the latter seems a bit off as an explanation of “which agent”, since situations can’t be blamed, and agency talk is about our instinct for blame, responsibility, and simplified explanation.

These kinds of questions are very natural to us. The engage with our intuition, our animal concern for patterns and causality, and often with conventions and structures defined in law. But the question of whether something “really is” an agent is rarely a sensible one to be asking. Agent id not a good rdf type; it’s a utility hack, and a shorthand for “people, orgs and maybe some stuff like that”. Is the Vatican an agent? Wales? The Spanish Olympic team? The moon?

Writing “things that might be described as having done something” in a serious font on a carefully maintained site does not bring gravitas or clarity to the underlying non-definition.

Being a do-er isn’t an intrinsic characteristic of a thing but tied up with describing how it plays a part in some situation- creating, publishing etc. Being an Organization or Person also has some fuzzyness but a lot less.

Any webpage can be a software agent, anything throwable can be an agent of destruction, anything that interacts with other pieces of the universe can be usefully described as having created changes in the world.

If what you really want is just to say “the values of the /xyz property can be Persons or Organizations”, there are plenty of other ways to just express that - English, OWL, SHACL-ShEx etc. Maybe just do that.

An Agent type here can be a useful fiction to bundle together a few things that often show up in similar settings but which of these two deeply and fundamentally handwavey definitions to reference on the basis of governance and supposed quality is the height of busywork!

</>

On Thu, 20 May 2021 at 02:10, Simon Cox @.***> wrote:

DCAT is a bit bogged-down by using some FOAF terms, while even the authors of FOAF have long since moved on to other vocabularies (esp. Schema.org).

AFAICT there are no obvious like-for-like replacements for foaf:homepage and foaf:primaryTopic.

But it would be a trivial to replace foaf:Agent with dcterms:Agent. I can't actually imagine what problems it could cause - @makxdekkers https://github.com/makxdekkers @andrea-perego https://github.com/andrea-perego?? It is only pointed to by dcterms:creator and dcterms:publisher so it would at least be more consistent with DCMI to use the DC class instead of reaching sideways into another vocabulary of dubious quality and governance.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/dxwg/issues/1367, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGJSVODVLKSWBEJP6JTTOROQ7ANCNFSM45FZRSWA .

makxdekkers commented 3 years ago

https://www.dublincore.org/collaborations/foaf/DCMI_FOAF_Cooperation/DCMI_FOAF_Agreement/ (Makx is still listed as a signatory- maybe we should update that?)).

Why would you want to update that? I did sign the agreement in my previous role. No need to alter history.

makxdekkers commented 3 years ago

BTW to celebrate Schema.org’s 10th birthday I want at least to update FOAF’s terms like Person for consistency with Schema.org (and tweaks in the other direction too if need be), including equivalence statements.

I assume that you would still respect the DCMI Generic Namespace Policy that is part of the DCMI FOAF Agreement, and in particular "the meanings of terms should evolve according to known change management policies". Would this mean the changes are going to be agreed with the DCMI Usage Board, of which you are a member?

danbri commented 3 years ago

@makxdekkers I was reading it as a live document (it has this month's date in the footer), i.e. that it represents ongoing commitments, and wasn't sure you'd be happy being considered as a current representative of DC Ltd. Fine if is a frozen snapshot!

Regarding known change management, the FOAF spec makes a few points to set expectations:

In addition to this, the agreement with DCMI adds "and commits to make no semantic changes in the FOAF vocabulary without advance public notice of at least two weeks."

I don't believe anyone (including @tombaker) ever read this as requiring changes to FOAF to be agreed with Dublin Core (or vice-versa), it was more a collaboration to ensure that namespace documentation and URI/dns management concerns were addressed. For example Tom and I spoke a couple of weeks ago about the strengths and weaknesses of depending on the purl.org system.

makxdekkers commented 3 years ago

@makxdekkers I was reading it as a live document (it has this month's date in the footer), i.e. that it represents ongoing commitments, and wasn't sure you'd be happy being considered as a current representative of DC Ltd. Fine if is a frozen snapshot!

Of course, I can't be considered a representative of DCMI Ltd. -- which, by the way, does not exist in that legal sense anymore.

If I understand correctly, @dr-shorthair made a point that FOAF is no longer actively maintained, and that, for Agent, there is an alternative at DCMI, which also creates more consistency as the properties for which foaf:Agent is the domain are Dublin Core properties. I guess there could be different opinions about this. In my opinion, it makes sense to make the change.

danbri commented 3 years ago

We haven't changed it for a while, but that's often true of Dublin Core too. Why mess with success? ;)

On Thu, 20 May 2021 at 17:37, makxdekkers @.***> wrote:

@makxdekkers https://github.com/makxdekkers I was reading it as a live document (it has this month's date in the footer), i.e. that it represents ongoing commitments, and wasn't sure you'd be happy being considered as a current representative of DC Ltd. Fine if is a frozen snapshot!

Of course, I can't be considered a representative of DCMI Ltd. -- which, by the way, does not exist in that legal sense anymore.

If I understand correctly, @dr-shorthair https://github.com/dr-shorthair made a point that FOAF is no longer actively maintained, and that, for Agent, there is an alternative at DCMI, which also creates more consistency as the properties for which foaf:Agent is the domain are Dublin Core properties. I guess there could be different opinions about this. In my opinion, it makes sense to make the change.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/dxwg/issues/1367#issuecomment-845275646, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGK5X673SITXIWJXNSDTOU3FJANCNFSM45FZRSWA .

dr-shorthair commented 3 years ago

Thanks @makxdekkers - yeah, that is essentially my point. I was updating the DCAT summary diagram and experienced a bit of whiplash walking round the backbone flipping from namespace to namespace (please don't anyone try to turn that into an image). The appearance of foaf:Agent in that place in the diagram, joined from some DC properties, just seems unnecessary. I think the comments from @danbri above confirm this - the actual class name is not important, the intention is, so why challenge people with a namespace switch which adds no value.

dr-shorthair commented 3 years ago

@danbri I didn't intend to cast shade on FOAF. It's been useful. But since DCAT re-uses a lot of DCMI terms then that is a big dependency that ain't going away. OTOH, the dependency on FOAF is minimal, and can be further reduced with this small change at the RDF level. Seems to me that reducing dependencies is generally beneficial for implementation and maintenance.

danbri commented 3 years ago

I actually agree. It would make more sense to use Schema.org since there are many many more terms in that namespace that could be useful; but I can understand if that route is not appealing. anyway, change vocabs for pragmatic reasons not because either org curates its barely operational definitions of “Agent” better.

Are there other kinds of Agent than Org, Person we care about here?

On Fri, 21 May 2021 at 02:31, Simon Cox @.***> wrote:

@danbri https://github.com/danbri I didn't intend to cast shade on FOAF. It's been useful. But since DCAT re-uses a lot of DCMI terms then that is a big dependency that ain't going away. OTOH, the dependency on FOAF is minimal, and can be further reduced with this small change at the RDF level. Seems to me that reducing dependencies is generally beneficial for implementation and maintenance.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/dxwg/issues/1367#issuecomment-845588563, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGJDT6ZHFMONFWAQ4OTTOWZYLANCNFSM45FZRSWA .

makxdekkers commented 3 years ago

@danbri There are certainly environments where quality of curation of semantics -- e.g. under responsibility of a trustworthy organisation with a clearly documented and transparent maintenance process -- is one of the key decision points.

makxdekkers commented 3 years ago

@danbri There are certainly environments where quality of curation of semantics -- e.g. under responsibility of a trustworthy organisation with a clearly documented and transparent maintenance process -- is one of the key decision points.

But I don't think that was the issue here.

danbri commented 3 years ago

Perhaps we agree. Putting a rough wine in a fancy bottle in a posh wine cellar doesn’t make it better wine. It may make it more expensive, so long as nobody tries drinking it. The “Agent” type is no better defined in either of its formulations - it’s a hack that serves a pragmatic purpose.

On Fri, 21 May 2021 at 09:18, makxdekkers @.***> wrote:

@danbri https://github.com/danbri There are certainly environments where quality of curation of semantics -- e.g. under responsibility of a trustworthy organisation with a clearly documented and transparent maintenance process -- is one of the key decision points.

But I don't think that was the issue here.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/dxwg/issues/1367#issuecomment-845755867, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGMEDLHNRJGXU6DM4STTOYJOVANCNFSM45FZRSWA .

makxdekkers commented 3 years ago

@danbri Lots of people have been 'drinking' both wines, DCMI's and FOAF's, and, as far as I know, nobody is complaining, so the definitions can't be that bad ;-)

danbri commented 3 years ago

:))

On Fri, 21 May 2021 at 09:43, makxdekkers @.***> wrote:

@danbri https://github.com/danbri Lots of people have been 'drinking' both wines, DCMI's and FOAF's, and, as far as I know, nobody is complaining, so the definitions can't be that bad ;-)

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/dxwg/issues/1367#issuecomment-845786345, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJSGITHTYUS3HEZBBOQ3DTOYMJNANCNFSM45FZRSWA .

kcoyle commented 3 years ago

The issue may not be the Agent term itself but the the context in which it is used. The DCAT editors draft gives dcterms:creator a range of foaf:agent, whereas dcterms:creator is already defined with a rangeIncludes of dcterms:Agent. Ditto dcterms:publisher. The FOAF range on these appears to be redundant, but if there is a desire to specify the expected range, then using dcterms:Agent would make sense.

andrea-perego commented 3 years ago

I think the main point in recommending the use of FOAF since the first version of DCAT was that DCTERMS does not provide specific terms for describing agents.

To my knowledge, the use of FOAF in DCAT is not causing issues - maybe with one exception, i.e., that FOAF does not provide terms to specify relationships between agents of the type affiliation, sub-organisation, and similar. The cases I'm aware of address this gap by using the W3C Organization Ontology to complement FOAF. (BTW, I raised this point in https://github.com/w3c/dxwg/issues/765)

Said that, I don't see any specific issues in changing the range restriction for dcterms:creator, dcterms:publisher, etc. and align with DCTERMS, provided that we keep the recommendation of using FOAF in the usage notes of these properties - which now read:

Resources of type foaf:Agent are recommended as values for this property.

andrea-perego commented 2 years ago

As there has been no further discussion in the thread, I propose we close this issue.