Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mapping to http://schema.org/SoftwareApplication #20

Open
elf-pavlik opened this issue Nov 7, 2013 · 10 comments
Open

mapping to http://schema.org/SoftwareApplication #20

elf-pavlik opened this issue Nov 7, 2013 · 10 comments
Assignees

Comments

@elf-pavlik
Copy link

i see mention of work on mapping foaf:Person to schema:Person
maybe we could find useful mapping of doap:Project to schema:SoftwareApplication ?

related: #9

@ewilderj ewilderj self-assigned this Aug 11, 2017
@ewilderj
Copy link
Owner

Yes, DanBri and I briefly talked earlier this week about schema.org integration/mapping. I will set up some time to chat with him about this.

@csarven
Copy link

csarven commented Aug 15, 2017

There is https://dokie.li/ a doap:Project. (Aside: It should probably be https://dokie.li/#project a doap:Project instead.)

I'm approaching this with an interest to use prov:wasGeneratedBy/as:generator where it points at either the "project" or "application". doap:Project seems to include/acknowledge the concept of application, but probably more since it is not only about the application itself.

@kjetilk
Copy link
Collaborator

kjetilk commented Aug 15, 2017

Yeah, I'm not sure I feel doap:Project and schema:SoftwareApplication to be easily mapped, as @csarven says, a project is not just about the application. But then, owl:sameAs is not the only option for mapping, and I'm sure @danbri would have a clear and thoughful opinion :-)

@csarven
Copy link

csarven commented Aug 16, 2017

I think this issue should be rephrased to potential relationships between the concepts, and not necessarily a particular "mapping". Understanding and clarifying the intentions and boundaries of what's here is more useful I think. Mapping may or may not be necessary.

@olberger
Copy link

I think there used to be a confusion between project and program in various uses of DOAP, but I'd like to draw attention to the fact that if one wants to model organisations developers and software, then it would be interesting to differentiate the project (as an organisation) developing the software, from the software itself.

Of course this is just rethorical, and my work in this field dates back a few years (cf. https://www-public.tem-tsp.eu/~berger_o/weblog/tag/doap/)

@danbri
Copy link

danbri commented Aug 16, 2017

So foaf:Person and schema:Person mean essentially the same thing, the definitions are pretty close.

Last time we rev'd the FOAF spec I put in some of the more obvious mappings, although only the Person one is also declared within schema.org's data files.

Since DOAP was built alongside FOAF we probably ought to take the opportunity to do a quick compare/contrast on any things still missing from schema.org that were in FOAF. Organization is in both. We don't need a lot of the FOAF classic stuff (dnaChecksum's time may yet come, but er, no thanks; mbox_sha1sum needs mothballing etc.).

I've never been sure what to do about Project, Group and Organization. FOAF had all 3. Currently Project is not a subtype of Organization although you could make the case for that. Group is also an oddity, in that it supports a) lists of people (e.g. bookmarked or followed on Twitter or categories in a contacts manager) b) lists of people who are actually in some sense aware they are a group.

My suggestion is that we could add "Project" to schema.org as a subtype of Organization and then figure out how projects and software applications relate.

Another topic I've been meaning to raise with @ewilderj is the line between software distributions and datasets, which is becoming more blurred over time...

@elf-pavlik
Copy link
Author

elf-pavlik commented Aug 18, 2017

Somehow I have hard time to see that those properties with rdfs:domain doap:Project describe an Organization and not SoftwareApplication (the code base not particular deployment)

@prefix doap: <http://usefulinc.com/ns/doap#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

doap:release
  rdfs:domain doap:Project ;
  rdfs:range doap:Version .

doap:repository
  rdfs:domain doap:Project ;
  rdfs:range doap:Repository .

doap:download-page
  rdfs:domain doap:Project .

doap:bug-database
  rdfs:domain doap:Project .

doap:screenshots
  rdfs:domain doap:Project .

doap:programming-language
  rdfs:domain doap:Project .

doap:implements
  rdfs:domain doap:Project ;
  rdfs:range doap:Specification .

doap:vendor
  rdfs:domain doap:Project .

When it comes to Organization as 'project team', I see that often smaller software projects have maintainers and contributors but they don't affiliate together as any kind of Organization, the software itself acts as something they relate to, not and Organization. Also some organizations often work on multiple software project, while various people have various roles in the organization, each of them can have different relationship with each of the projects (maintainer, contributor, tester etc.)

@ewilderj
Copy link
Owner

Does anybody care about this still? It doesn't seem that we ever came to a conclusion of any kind.

@danbri
Copy link

danbri commented Jun 11, 2024 via email

@kjetilk
Copy link
Collaborator

kjetilk commented Jun 11, 2024

Fwiw https://schema.org/Project now exists, as anticipated in my 2017 post

Then, I think it makes sense to map this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants