dangling incomplete sentence

[jonassmedegaard]

The page section https://docs.atomicdata.dev/interoperability/rdf.html#why-these-changes ends like this:

I've asked two colleagues working on RDF about this constraint, and both were critical. The reason

The reason what?

Great text - which makes it so much more frustrating to leave the reader hanging in suspense over that detail... :-)

[joepio]

Thanks for letting me know! There's a bit more of these unfinished sentences in the project... Sorry, it's the chaotic way I tend to write things down.

Anyways, to answer the question:

Two separate RDF developers (who did not know each other) gave me the exact same reason for using Named Graphs: They wanted to extend the schema.org ontology by adding properties to these items in a local graph.

I don't think even this usecase is appropriate for named graphs. They were actually using an external resource that did not provide them with the things they needed. The things that they would add (the translations) are not re-usable, so in the end they will just keep spreading a URL that doesn't provide people with the things that they will come to expect. The schema.org URL still won't provide the translations that they wrote!

I believe a better solution is to copy the resource (in this case a part of the schema.org ontology), and extend it, and host it somewhere else, and use that URL. I'd like to see a more organic usage of URLs that actually provide meaningful and valuable machine readable properties, including translations and icons.

[jonassmedegaard]

Do I understand you correctly that your recommendation for the schema.org example is to formally create a subclass of the ontology?

...because making a fork with different content (added triples to cover a new language strings) without formally renaming the project sounds bad to me.

[jonassmedegaard]

There's a bit more of these unfinished sentences in the project...

Right. Just spotted another one at the end of https://docs.atomicdata.dev/schema/intro.html#atomic-schema

Sorry, it's the chaotic way I tend to write things down.

I can suggest to add the word FIXME whenever you are leaving something incomplete.
That way it is possible to grep for incomplete stuff, and you might even add such grep check as part of a git push hook or an mdbook publish hook (if such exist - I have not yet embraced that tool myself).

[joepio]

Fixed the dangling sentences!

I can suggest to add the word FIXME whenever you are leaving something incomplete.

Good idea!

Right. Just spotted another one at the end of https://docs.atomicdata.dev/schema/intro.html#atomic-schema

Thanks, fixed it!

Do I understand you correctly that your recommendation for the schema.org example is to formally create a subclass of the ontology? ...because making a fork with different content (added triples to cover a new language strings) without formally renaming the project sounds bad to me.

Well, to be honest, I think forking it with a new subject is preferable to re-using it and add properties to it, but is still not the optimal scenario. Ideally, you'd create a PR and add properties / translations to the source, like what is happening here in this repo (see #21). But in any case - you want the world to be able to use your improvements!

[jonassmedegaard]

Well, to be honest, I think forking it with a new subject is preferable to re-using it and add properties to it, but is still not the optimal scenario. Ideally, you'd create a PR and add properties / translations to the source, like what is happening here in this repo (see #21). But in any case - you want the world to be able to use your improvements!

Obviously the optimal scenario is a different collaborative one than the scenario you presented: I assume those choosing to work elsewhere has first considered and given up on the collaborative approach for whatever reason.