Il giorno 12/ago/2013 05:26, Tom Morris tfmor...@gmail.com ha scritto:
Is it intentional to restrict the definition to personal pseudonyms?
That doesn't cover all uses of them For example, there are house
pseudonyms used by publishing houses which are associated with a series and
the
Cases like this - where the pseudonym is a (collective) entity in itself -
would seem to be a good case for member of relationships - Henri Cartan
[is a member of] Nicholas Bourbaki as John Lennon [is a member of] the
Beatles.
A free-text pseudonym for each of the Bourbaki authors would mean
Hoi,
When an item is a member of a list, the item is likely to be written
differently dependent on the language and script. When there is a
free-text referral, it loses its flexibility ... eg 靈高史達 is a member of
the Beatles grin obviously /grin
Thanks,
Gerard
On 12 August 2013 11:44,
My feelings are strong towards one-line-per-fact.
Large RDF data sets have validity problems, and the difficulty of
convincing publishers that this matters indicates that this situation will
continue.
I’ve thought a bit about the problem of the “streaming converter from
Turtle to
2013/8/11 Jane Darnell jane...@gmail.com:
Hmm, I am not quite sure how to see this. Places and people yes: It
would be nice to have the geo coordinates on Wikidata and for the
artist and writers
I am not sure I get what geocoordinates means for people.
I also agree for the book and the
With respect to the RDF export I'd advocate for:
1) an RDF format with one fact per line.
2) the use of a mature/proven RDF generation framework.
Optimizing too early based on a limited and/or biased view of the
potential use cases may not be a good idea in the long run.
I'd rather keep it simple
geocoordinates can be linked to places; creator templates, book
templates, and artwork templates can all be linked to people.
The problem is if you store the data on WikiData, but do not allow the
content to show up on WikiCommons (due to copyright problems), then
where does data-curation take
On 12/08/13 17:56, Nicolas Torzec wrote:
With respect to the RDF export I'd advocate for:
1) an RDF format with one fact per line.
2) the use of a mature/proven RDF generation framework.
Optimizing too early based on a limited and/or biased view of the
potential use cases may not be a good idea
