Re: [Crm-sig] Issue 616: shortcuts in P50 has current keeper, P52 has current owner, P55 has current location
Dear all,
I fully agree with Christian-Emil's observation that
> The current properties P50, P52 and P55 need external curation and
> also break the basic assumption that a CIDOC-CRM KB/database
> store accumulate history.
This is a point I had to raise over and over again in discussions about
database design: there is no notion of "now" if we are dealing with persistent
data.
> Maybe it is time to get rid of them?
Definitely. The reason why the idea of a "current" state of affairs is so
deeply rooted in the database world seems to come from the fact that almost any
textbook on the subject has silly examples such as "student: { name: Carla
Jones, age: 23 }".
Best,
Detlev
> Christian-Emil Smith Ore via Crm-sig hat am 28.11.2022
> 12:31 CET geschrieben:
>
>
> Dear all,
> Wolfgang points to the fact that the 'current' properties is not defined in a
> consistent way, which of course they should have been. The textual scope
> notes says 'if and only if' which should be expressed as bidirectional
> implication, ⇔ (equivalence). Below I quite from an email exchange between
> Carlo and me. This may explain the issue:
>
> C-E:
> There are several axioms in CRM of the form lefthandside(x,y)⇒
> (∃z)[righthandside(x,y,z)], which is not a good thing, if I understand you
> right, due to efficient machine reasoning and the time it will take to find a
> needle z in the haystack.
>
> Carlo:
>
> Precisely. The computer enters into a combinatorial examination of cases and
> basically may never come back.
>
> and Carlo writes earlier in his reply, about claiming the existence of some
> individual on the right hand side of the implication:
> ' it's not outside of the model, it's that we do not know what to do with it,
> as you said, having a bunch of these "unknown" guys in the KB breaks
> efficiency. I understand that efficiency is an engineering issue, but in the
> end, we are engineers. '
>
> In my earlier days when I worked with formal logic and models, I didn't care
> very much about efficiency. However, I fully understand Carlo and also see
> the point that we formulate the FOL so that it can be efficiently computable.
> This is one reason to drop the bidirectional implication implication in the
> properties P50, P52 and P55.
>
> There is also another issue. The current properties P50, P52 and P55need
> external curation and also break the basic assumption that a CIDOC-CRM
> KB/database store accumulate history. It would have been better if the
> current properties are implemented as named and stored queries with the
> ting/person as argument. The original reason for introducing the current
> properties was they were used in some museum databases in the 1990ies,. Maybe
> it is time to get rid of them?
>
> Best,
> Christian-Emil
>
>
>
>
> P50 has current keeper
>
> This property is a shortcut for the more detailed path from E18 Physical
> Thing through, P30i custody transferred through, E10 Transfer of Custody, P29
> custody received by to E39 Actor, if and only if the custody has not been
> surrendered by the receiving actor at any later time.
> FOL:
>
>
> P50(x,y) ⇐ (∃z) [[E10(z) ⋀ P30i(x,z) ⋀ P29(z,y) ]
> ⋀ ¬ (∃w) [E10(w) ⋀ P30i(x,w) ⋀ P28(w,y)⋀ P182(z,w)]]
>
>
>
>
> P52 has current owner
>
> This property is a shortcut for the more detailed path from E18 Physical
> Thing through, P24i changed ownership through, E8 Acquisition, P22
> transferred title to to E39 Actor, if and only if this acquisition event is
> the most recent.
> FOL:
>
>
> P52(x,y) ⇐ (∃z) [[E8(z) ⋀ P24i(x,z) ⋀ P22(z,y) ]
> ⋀ ¬ (∃w) [E8(w) ⋀ P24i(x,w) ⋀ P23(w,y)⋀ P182(z,w)]]
>
>
>
>
> P55 has current location
>
> This property is a shortcut. A more detailed representation can make use of
> the fully developed (i.e., indirect) path from E19 Physical Object,through,
> P25i moved by,E9 Move, P26 moved to to E53 Place if and only if this Move is
> the most recent.
>
> P55(x,y) ⇐ (∃z) [ [E9(z) ⋀ P25i(x,z) ⋀ P26(z,y)]
> ⋀ ¬ (∃w) [E9(w) ⋀ P25i(x,w) ⋀ P27(w,y)⋀ P182(z,w)]]
>
>
>
>
>
>
> ___ Crm-sig mailing list
> Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
Re: [Crm-sig] URI Management [Issue 460]
Dear all,
good to see that the idea of publishing some of the CIDOC CRM as a Linked Data
resource is finally gaining traction.
Concerning versioning, I'm also in favour of a single, un-versioned URI
namespace, as long as there is a way of knowing which version is currently
being served (e.g. by including statements from the W3C VoID vocabulary).
Nevertheless, having previous versions accessible via additional, versioned
namespaces can be useful for tracing conflicts that may arise from
non-backward-compatible changes.
Regarding the question of "star view" vs. complete schema, I'd suggest to
follow the common practice of serving just the direct statements where the
class or property URI occurs as the subject. This is basically what you get
from SPARQL using a DESCRIBE query. In an HTML view, you probably want to
see more context such as inferred statements. Pure RDF however, is intended for
machine processing and if you make all of the RDFS availabe via SPARQL (in
addition to resolving URIs directly), then anyone is free to construct their
own "star view" as required.
Concerning HTTP 3xx redirections, I would not take this too far. It may make
some sense for HTML pages, but less so on the level of RDF processing.
Just a few thoughts from the depths of the engine room ...
Detlev
> Pavlos Fafalios via Crm-sig hat am 27.09.2021 16:03
> geschrieben:
>
>
> Dear Robert,
>
> Thank you for your reply (and the interesting pointer to the FOAF's
> experience with URIs :)
>
> I fully agree. It seems that Option B1 ("always use an unversioned base URI
> in all RDFS versions") is the better way to go.
>
> Let's see if there are other opinions on this.
>
> Best regards,
> Pavlos
>
>
> On Mon, Sep 27, 2021 at 4:33 PM Robert Sanderson wrote:
> >
> >
> > Reordering to most important first..
> >
> > > (C) BASE URI (NAMESPACE) FOR CLASSES AND PROPERTIES What base URI should
> > > we use for the classes and properties of each version when serving RDF
> > > content? There are three options:
> > > Option B1. Always use an unversioned base URI, i.e.,
> > > http://www.cidoc-crm.org/cidoc-crm/ for all ontology versions.
> >
> >
> > This is the correct answer, according to 2 decades of RDF / Semantic Web
> > experience.
> > In particular, FOAF, one of the earliest RDF ontologies and written by one
> > of the original authors for RDF Dan Brickley, warns us in the specification:
> >
> > > Much of FOAF now is considered stable. Each release of this specification
> > > document has an incrementally increased version number, even while the
> > > technical namespace ID remains fixed and includes the original value of
> > > "0.1". It long ago became impractical to update the namespace URI without
> > > causing huge disruption to both producers and consumers of FOAF data.We
> > > are left with the digits "0.1" in our URI. This stands as a warning to
> > > all those who might embed metadata in their vocabulary identifiers.
> > (emphasis added). http://xmlns.com/foaf/spec/
> >
> > Please, do NOT put a version number into the URIs. It makes everyone's
> > lives worse, and breaks interoperability between systems. It also makes it
> > much harder for people to upgrade systems and retract/republish data,
> > meaning we will leave folks behind in previous versions. It also makes it
> > harder to aggregate data, as the same property (say, P2) has different URIs
> > in different systems.
> >
> > I would go so far as to say that, given we already have different RDFS and
> > OWL namespaces, that if there was further fragmentation, it would further
> > harm adoption and most users would simply pick the one that was easiest for
> > them given the already incompatible URIs.
> >
> > In looking at similar topics (XML namespaces, API versions) the results are
> > the same -- URIs should be persistent, and versions / dates make them
> > either less persistent or appear out of date, both of which are harmful.
> >
> > > Thanasis has already made a point about not using versioned base URI:
> > > "I am suggesting that classes do not need versions at all. Doing
> > > reasoning on a per class and per version basis would be bad practice, no?
> > > One would expect that the whole RDF/OWL representation would be used for
> > > reasoning. I think class URIs are only used as identifiers. This also
> > > avoids the problem of ensuring correct older versions for deprecated
> > > classes."Thanasi, could you please elaborate more on this? It's not clear
> > > to us why/how reasoning considering a particular ontology version is
> > > affected when versioned URIs are used for the classes and properties.
> >
> > As above, but Thansis is 100% correct - URIs are used as identifiers. We
> > wouldn't change the numbers in the ontology (E22, P2 etc) ... in RDF the
> > URI has the same function.
> >
> >
> >
> > On Mon, Sep 27, 2021 at 6:41 AM Pavlos Fafalios via Crm-sig
> > wrote:
> > > Dear all,
> > >
[Crm-sig] Fwd: Re: Proposal/though: Add URLs to official documentation
Sorry, this was meant to go to the list: > -- Ursprüngliche Nachricht -- > Von: Detlev Balzer > An: George Bruseker > Datum: 20.07.2021 17:52 > Betreff: Re: [Crm-sig] Proposal/though: Add URLs to official documentation > > > > George Bruseker via Crm-sig hat am 20.07.2021 11:46 > > geschrieben: > > > > > > Dear all, > > > > Many people try to use the CIDOC CRM in order to build sustainable, > > reusable data sources and connect into a wider linked open data web. > > > > When they do so, they would like to easily be able to find / use the URIs > > for the classes and properties that the standard declares. > > I'm one of those. > > The standard recipe would be to follow the linked data principles as > explained e.g. in the http://linkeddatabook.com/ . While the technical specs > may look a bit intimidating at first, turning an RDF graph plus documentation > into fully compliant linked data source requires only modest technical skills > and effort. > > All the required pieces for URL routing come with commonly used web servers, > and converting RDF on-the-fly into any desired format is handled out of the > box by open source RDF stores such as RDF4J or Fuseki. Any aspiring young web > programmer out there to take on the challenge? > > Detlev > > > > > The official documentation does not include this information in a handy way. > > > > Proposal for discussion: include the URIs for the classes and properties as > > clickable links that resolve to the online space where they are maintained > > in the word/pdf specification. > > > > Discuss! > > > > Best, > > > > George > > ___ Crm-sig mailing list > > Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
Re: [Crm-sig] CIDOC CRM URI management
> Martin Doerr hat am 16. Januar 2020 um 13:27
> geschrieben:
>
> (...)
> At FORTH we will implement anything that is regarded good practice, and
> does not create a manual overhead we cannot manage.
For formal specifications such as ontologies, there is a widely adopted pattern
for change management which goes like this:
http://www.cidoc-crm.org/cidoc-crm/ always resolves to the latest version, while
http://www.cidoc-crm.org/cidoc-crm/{version}/ always resolves to the particular
{version} given in the URI.
There can be any number of versions, and the latest one is both referenced
through the un-versioned namespace and through the one with the most recent
version number (or publication date, if that is used for versioning).
Alternatively, the most recent version could be labelled explicitly as the
current one, e.g. http://www.cidoc-crm.org/cidoc-crm/current/
Application developers must then decide what kind of stability they prefer:
stability of the namespace URI, or stability of the content retrieved from a
URI. Evidently, one cannot have both.
Maintenance effort for this pattern is minimal: Just publish each new version
under its versioned namespace and then, any time another version comes out,
adjust the non-versioned namespace so that it will resolve to the most recent
version. Most modern Web frameworks have a URL routing facility which makes
this fairly easy.
I should not forget to say that LOD best practice also demands that URIs
support content negotiation, as assumed throughout all recommendations in the
http://linkeddatabook.com/
Best,
Detlev
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
Re: [Crm-sig] ISSUE P114-P120 VOTE
Thanks Martin and Christian-Emil, for the explanations. Honestly, I had forgotten about P137 ... and P182 ... Therefore I revise my vote to YES. Detlev > Christian-Emil Smith Ore hat am 12. Januar 2020 um > 20:33 geschrieben: > > > Dear all, > > It may seem very dramatic to move the P114-P120 to CRMarcheo. It is not > These properties correspond more or less to the Allen operators which are not > always ideal. Several years ago the SIG introduced the following alternatives: > > > P173 starts before or at the end of (ends with or after the start of): E2 > Temporal Entity > P174 starts before (starts after the start of): E2 Temporal Entity > P175 starts before or with the start of (starts with or after the start of) : > E2 Temporal Entity > P176 starts before the start of (starts after the start of): E2 Temporal > Entity > P182 ends before or at the start of (starts with or after the end of) : E2 > Temporal Entity > P183 ends before the start of (starts after the end of) : E2 Temporal Entity > P184 ends before or with the end of (ends with or after the end of) : E2 > Temporal Entity > P185 ends before the end of (ends after the end of): E2 Temporal Entity > > These eight properties are superproperties of the P114-P120 as shown below. > The original idea (when P173-P185 where introduced, entirely was to > deprecate the P114-P120. However, it is too radical to simply remove them > as the two comments in this email exchange show. Since they are considered > useful in archaeology the idea is to put them there. > > Best, > Christian-Emil > > > > > P173 starts before or with the end of (ends after or with the start of) > > P119i - is met in time by > > P174 - starts before the end of (ends after the start of) > > P118i -- is overlapped in time by > > P134 -- continued (was continued by)E7 Activity <-> E7 > Activity > > P175 -- starts before or with the start of (starts after or with the > start of) > > P176 -- - starts before the start of (starts after the start of) > > P115i -- - - is finished by > > P117i -- - - includes > > P118 -- - - overlaps in time with (is overlapped in time by) > > P182 -- - - ends before or at the start of (starts after or with > the end of) > > P119 -- - - - meets in time with (is met in time by) > > P183 -- - - - ends before the start of (starts after the end of) > > P120 -- - - - - occurs before (occurs after) > > P116 -- - starts (is started by) > > P114 -- - is equal in time to > > P184 -- ends before or with the end of (ends with or after the end of) > > P114 -- - is equal in time to > > P115 -- - finishes (is finished by) > > P185 -- - ends before the end of (ends after the end of) > > P116 -- - - starts (is started by) > > P117 -- - - occurs during (includes) > > P182 -- - - ends before or at the start of (starts after or with > the end of) > > P118 -- - - overlaps in time with (is overlapped in time by) > > > > > > From: Crm-sig on behalf of Francesco Beretta > > Sent: 12 January 2020 11:54 > To: crm-sig@ics.forth.gr > Subject: Re: [Crm-sig] ISSUE P114-P120 VOTE > > > Dear Martin and Christian-Emil, > > 1. is there any replacement foreseen for these quite useful properties in > CRMbase ? > > 2. for the sake of clear documentation and legacy the vote proposal should be > associated with the list and links to the correspondent issues, shouldn't it ? > > 3. I'm quite in favour of this vision of a core (CRMbase) and extensions (the > family) but shouldn't we start working on a clear formalization of this > integration (cf. e.g. the TEI) – or is this already done and I just don't > know where to find it ? > > 4. One aspect of this task is to have a consistent URI definitions and > dereferencing for CRMbase and family and their different versions. > > > I think point 1 and 2 should be clarified to the voters before we vote. Just > avoir B..x.. situations. > > > All the best > > Francesco > > > Le 12.01.20 à 11:13, Martin Doerr a écrit : > Dear All, > > If you agree that > > "the following Allen's temporal relations should be deprecated in the CRMbase > and reappear in CRMarcheo: > > P114 is equal in time to > P115 finishes (is finished by) > P116 starts (is started by) > P117 occurs during (includes) > P118 overlaps in time with (is overlapped in time by) > P119 meets in time with (is met in time by) > P120 occurs before (occurs after)" > PLEASE VOTE "YES" > otherwise "NO" > Best, > Martin > > On 1/12/2020 10:29 AM, Christian-Emil Smith Ore wrote: > Dear all, > In the October 2019 meeting in Iraklio, we did a general cleanup of the > CRM-document based on Martin's and my general review. It was a general > understanding that
Re: [Crm-sig] ISSUE P114-P120 VOTE
I vote NO. Temporal relationships are not only useful in archaeology. Time is such an important dimension that I think that these should remain part of the core ontology. Detlev > Martin Doerr hat am 12. Januar 2020 um 11:13 > geschrieben: > > > Dear All, > > If you agree that > > "the following Allen's temporal relations should be deprecated in the > CRMbase and reappear in CRMarcheo: > > P114 is equal in time to > P115 finishes (is finished by) > P116 starts (is started by) > P117 occurs during (includes) > P118 overlaps in time with (is overlapped in time by) > P119 meets in time with (is met in time by) > P120 occurs before (occurs after)" > PLEASE VOTE "YES" > otherwise "NO" > Best, > Martin > > On 1/12/2020 10:29 AM, Christian-Emil Smith Ore wrote: > > Dear all, > > In the October 2019 meeting in Iraklio, we did a general cleanup of > > the CRM-document based on Martin's and my general review. It was a > > general understanding that the SIG had decided that the following > > temporal relations should be deprecated in the CRMbase and reappear in > > CRMarcheo: > > P114 is equal in time to > > P115 finishes (is finished by) > > P116 starts (is started by) > > P117 occurs during (includes) > > P118 overlaps in time with (is overlapped in time by) > > P119 meets in time with (is met in time by) > > P120 occurs before (occurs after) > > > > However, I cannot find any traces of such a decision neither in the > > amendment part, in the minutes the previous two years nor in the list > > of issues. > > > > I suggest that this decision could be done by email vote. > > > > Best, > > Christian-Emil > > > > > > > > > > > > > > ___ > > Crm-sig mailing list > > Crm-sig@ics.forth.gr > > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > > -- > > Dr. Martin Doerr > > Honorary Head of the > Center for Cultural Informatics > > Information Systems Laboratory > Institute of Computer Science > Foundation for Research and Technology - Hellas (FORTH) > > N.Plastira 100, Vassilika Vouton, > GR70013 Heraklion,Crete,Greece > > Vox:+30(2810)391625 > Email: mar...@ics.forth.gr > Web-site: http://www.ics.forth.gr/isl > > ___ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
Re: [Crm-sig] P72 has Language
Dear George, Martin, this discussion made me curious whether or not I can confirm George's assertion that such statements are common in the cultural heritage field. EAC-CPF does have a language element, which is, however, only used to indicate in which language the name of a person or corporation is expressed. GND, the authority file for libraries in German-speaking countries, has a Language entity which is used for making statements about the "field of study" of a person. Other predicates for the person-language pair of entities do occur, but these are obvious data entry errors. Having extracted person-related data from a dozen or more cultural heritage projects, I don't remember any example where languages spoken or known by somebody have been considered in any other sense than relating to the documented activity, rather than to the (possibly un-instantiated) capacity of the person. Of course, this is just an observation that doesn't prove anything. Personally, I would tend towards Martin's view that there is little, if anything, to be gained by defining such kind of statement in a reference model such as the CIDOC CRM. Best wishes, Detlev > George Bruseker hat am 14. Oktober 2019 um 19:45 > geschrieben: > > > Dear Martin, > > The conversation began with a use case from an archive. I just inform that > this is also found in all the projects I work on for memory institutions. > They find it in scope, so looking further afield for what anthropologists > do doesn't seem like a necessary step? Though highly fascinating! > > Best > > George > > > > On Mon, Oct 14, 2019, 6:58 PM Martin Doerr wrote: > > > Dear George, All, > > > > As a second thought: > > > > I think documentation formats such as LIDO are an adequate place to add > > such useful properties to characterize items in a more detailed way, we > > would not put in the CRM analytically. Shapes, colors etc. being typical > > examples. > > > > Question: Are there formats from the archival world that use to describe > > the languages people speak? EAD CFP? > > Libraries are interested in the languages someone publishes in, not > > speaking. > > > > What are the anthropologists registering? Would they be interested in > > languages learned at school, or rather in the language used for > > communication in a typical group? Would they document people being > > incapable of communicating in that group? > > Or just infer language via group? > > > > How to distinguish native speakers from non-native? > > > > Would historians make cases of people that could not communicate in a > > given language, with societal effects? > > > > What about illiterate people? Speaking, not writing...? Maintaining oral > > history with great precision, etc. > > > > What about creoles ? > > > > Best, > > > > Martin > > > > On 10/14/2019 7:33 PM, Martin Doerr wrote: > > > > > > Dear George, > > > > The first principle of all is are there relevant queries that need that > > property for integrating disparate sources, which indeed provide such data, > > and is that research one we like to support with the CRM? > > > > Second, using p2 on E21 does the job, doesn't it? What is the added value > > of "knows language"? > > > > Next principle, keep the ontology small. Querying 1000 properties is > > already more than anybody can keep in mind. Each additional property has an > > implementation cost. We need strong arguments for relevance. > > > > It has been the mos t important success factor of the CRM to keep the > > ontology small and still expressive enough. If we loose this discipline, we > > will loose the whole project. > > > > Finally, we are not repeating in the CRM the way typically information > > systems document, but always tried to find a more fundamental > > representation. With that argument, we could never have introduced events. > > They did NOT appear in any of the typical systems at that time. It is a > > principle *not *to model all the valuable description elements, which are > > relevant to characterize an item, but not creating interesting links across > > resources. > > > > I did not say that it is a personal opinion that someone speaks a > > language. I said, this is observable. I document: Franco has spoken Latin, > > repeatedly? But talking about skills, is another level, it introduces a > > quality, which is hard to objectify, as Franco has pointed out. Actually, > > it is a typical classification problem, with all its boundary case > > questions, and the CRM is about relations between particulars. > > > > So, what is the* added value* against p2, and what are the typical > > research data and typical research questions for *integrating* such data, > > that cannot be answered with P2? > > > > Best, > > > > martin > > > > > > > > > > On 10/14/2019 4:24 PM, George Bruseker wrote: > > > > Dear Martin, > > > > Which is CEO’s proposition that you support? It gets lost in the string. > > Do you mean that a) a person speaking a language
Re: [Crm-sig] Issue 418 sparql end points hw
Hi George, one correction: http://sparql.europeana.eu/ doesn't require an access key. The SPARQL endpoint is open to anyone. And one addition: https://foko-project.eu/api/ uses the Erlangen CRM as data model (however, don't be surprised by the fact that quite a bit of the triplestore is occupied by a copy of the AAT). This thing is based on the WissKi platform (http://wiss-ki.eu/ ) and contains metadata about buildings and monuments in Eastern Europe. Cheers, Detlev > George Bruseker hat am 1. Oktober 2019 um 12:39 > geschrieben: > > > Dear all, > > Here is a link to a spreadsheet wherein sparql end points with crm data > available have been listed. I have been contact with as many providers as > i could directly. Further Matteo Lorenzini was able to add data from his > research. > > https://docs.google.com/spreadsheets/d/1x15RRKpYLjXjz0hBLxHXOf7alBY2k4opU2ZqBaRjM2I > > Given that at the last meeting we decided to go ahead with this, here is a > draft list. If you have more info, please add. If you think of other > metadata we should collect be suggest. Hopefully we can move the issue to > implementation through the next meeting. > > > > > Best > > George > ___ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig
Re: [Crm-sig] Using multiple instantiation
Center for Cultural Informatics >> >> Information Systems Laboratory >> >> Institute of Computer Science >> >> Foundation for Research and Technology - Hellas (FORTH) >> >> >> >> >> N.Plastira 100, Vassilika Vouton, >> >> GR70013 Heraklion,Crete,Greece >> >> >> >> Vox:+30(2810)391625 >> >> Email: mar...@ics.forth.gr <mailto:mar...@ics.forth.gr> >> >> Web-site: http://www.ics.forth.gr/isl >> >> >> >> ___ >> >> Crm-sig mailing list >> >> Crm-sig@ics.forth.gr <mailto:Crm-sig@ics.forth.gr> >> >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> >> -- >> *Richard Light* >> >> >> >> ___ >> >> Crm-sig mailing list >> >> Crm-sig@ics.forth.gr <mailto:Crm-sig@ics.forth.gr> >> >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> >> >> >> -- >> >> >> >> Dr. Martin Doerr >> >> >> >> Honorary Head of the >> >> >> Center for Cultural Informatics >> >> Information Systems Laboratory >> >> Institute of Computer Science >> >> Foundation for Research and Technology - Hellas (FORTH) >> >> >> >> N.Plastira 100, Vassilika Vouton, >> >> GR70013 Heraklion,Crete,Greece >> >> >> >> Vox:+30(2810)391625 >> >> Email: mar...@ics.forth.gr <mailto:mar...@ics.forth.gr> >> >> Web-site: http://www.ics.forth.gr/isl >> >> ___ >> Crm-sig mailing list >> Crm-sig@ics.forth.gr <mailto:Crm-sig@ics.forth.gr> >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> >> >> >> >> -- >> >> Dr. Martijn van Leusen >> >> Associate professor, Landscape Archaeology, Groningen Institute of >> Archaeology >> >> Poststraat 6, 9712ER Groningen (Netherlands) / phone +31 50 3636717 >> >> Chair, Examination Board for Arts, Culture and Archaeology / Chair, >> Faculty of Arts Advisory Board for Data Management policies >> >> Academia page <https://rug.academia.edu/MartijnvanLeusen> >> >> >> >> -- >> >> >> >> Dr. Martin Doerr >> >> >> >> Honorary Head of the >> >> >> Center for Cultural Informatics >> >> Information Systems Laboratory >> >> Institute of Computer Science >> >> Foundation for Research and Technology - Hellas (FORTH) >> >> >> >> N.Plastira 100, Vassilika Vouton, >> >> GR70013 Heraklion,Crete,Greece >> >> >> >> Vox:+30(2810)391625 >> >> Email: mar...@ics.forth.gr <mailto:mar...@ics.forth.gr> >> >> Web-site: http://www.ics.forth.gr/isl >> >> ___ >> Crm-sig mailing list >> Crm-sig@ics.forth.gr <mailto:Crm-sig@ics.forth.gr> >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> >> >> >> >> ___ >> Crm-sig mailing list >> Crm-sig@ics.forth.gr >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig > -- > *Richard Light* > > > ___ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > -- Detlev Balzer, Mecklenburger Landstr. 5, D-23570 Lübeck Tel (+49/0)4502-8896495, Mobil (+49)0173-6231233 PGP Fingerprint B5F3 6467 0615 1EB4 B602 8E41 DE70 8D59 0A8B BBD7
Re: [Crm-sig] Issue: Solution for Dualism of E41 Appellation and rdfs:label
this method for the RDFS implementation of the CRM: two ranges for > P1, namely E41 and rdf:Literal, and P1 superproperty of rdfs:label. > > Best, > > > > Martin > > -- > > -- > > Dr. Martin Doerr | Vox:+30(2810)391625| > > Research Director | Fax:+30(2810)391638| > >| Email: mar...@ics.forth.gr > <mailto:mar...@ics.forth.gr> | > > | > >Center for Cultural Informatics | > >Information Systems Laboratory| > > Institute of Computer Science| > >Foundation for Research and Technology - Hellas (FORTH) | > > | > >N.Plastira 100, Vassilika Vouton, | > > GR70013 Heraklion,Crete,Greece | > > | > > Web-site: http://www.ics.forth.gr/isl | > > -- > > > > ___ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > -- Detlev Balzer, Mecklenburger Landstr. 5, D-23570 Lübeck Tel (+49/0)4502-8896495, Mobil (+49)0173-6231233 PGP Fingerprint B5F3 6467 0615 1EB4 B602 8E41 DE70 8D59 0A8B BBD7
Re: [Crm-sig] ISSUE Label-free RDF classes PLEASE VOTE
I also vote YES.
Where natural-language names are desired for readability, why not allow for any
number of non-normative label sets? This would put Chinese or Armenian class
and property names on a par with the English ones, without compromising
interoperability as long as the distinction between URI and label is kept in
mind.
Best,
Detlev
Am 19.07.2018 um 18:39 schrieb Martin Doerr:
> Dear All,
>
> The current text "Expressing the CIDOC Conceptual Reference Model in RDF"
> (https://docs.google.com/document/d/1zCGZ4iBzekcEYo4Dy0hI8CrZ7dTkMD2rJaxavtEOET0/edit?ts=5b50b922)
>
> contains the phrase:
> "In addition, for convenience of implementation we have defined number-only
> classes and properties e.g. “E63” or “P2”, and declared each of them to be
> equivalent to the corresponding full form"
>
> In the past, this option was provided and widely rejected by users. I do not
> know of any installation using it.
>
> It was proposed again because CRM-SIG reserves the right to change labels
> without changing the code ("E63", "P2" etc.), in cases when the meaning is
> preserved but the existing label causes confusion and can be replaced by a
> more fitting or at least less confusing one. These changes are very rare, and
> explicit in the amendment of the respective version.
>
> Those of you who support:
> "In addition, for convenience of implementation we have defined number-only
> classes and properties e.g. “E63” or “P2”, and declared each of them to be
> equivalent to the corresponding full form"
> please vote *YES.
>
> *Those of you who support:
> "The English label is part of the definition of the RDF classes and
> properties. Number-only classes and properties e.g. “E63” or “P2”, are not
> provided". Other means of supporting migration between label versions to be
> discussed.
>
> please vote *NO.
>
> *(Those who believe the issue is not sufficiently formulated please vote
> "VETO". One or more "VETO" will stop the e-mail vote as a whole and postpone
> it to the next physical meeting)
>
> Best
>
> Martin
>
> --
> --
> Dr. Martin Doerr | Vox:+30(2810)391625|
> Research Director | Fax:+30(2810)391638|
>| Email: mar...@ics.forth.gr |
> |
>Center for Cultural Informatics |
>Information Systems Laboratory|
> Institute of Computer Science|
>Foundation for Research and Technology - Hellas (FORTH) |
> |
>N.Plastira 100, Vassilika Vouton, |
> GR70013 Heraklion,Crete,Greece |
> |
> Web-site: http://www.ics.forth.gr/isl |
> --
>
>
>
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
--
Detlev Balzer, Mecklenburger Landstr. 5, D-23570 Lübeck
Tel (+49/0)4502-8896495, Mobil (+49)0173-6231233
PGP Fingerprint B5F3 6467 0615 1EB4 B602 8E41 DE70 8D59 0A8B BBD7
Re: [Crm-sig] ISSUE: Shortcut semantics
Dear Vladimir, I'd second Martin's view from a very practical perspective. You've probably seen dozens of databases containing statements such as artifact A was created by agent B. If we assume that all of these statements imply the existence of a creation event, then we have a clear migration path in cases where additional information needs to find a suitable representation. Another use case is integrating "low-res" and "high-res" knowledge bases, where "low-res" statements have to be translated into a more complex representation even if no information is added during the process. Best regards, Detlev Am 11.09.2014 um 17:24 schrieb MARTIN DOERR: a few cases the shortcut implies a particular path so that the existence of the intermediates can be inferred. (such as "rights held by"). Hi Martin! In my opinion, a shortcut should never infer a long-path. Hi Vladimir, My question was about logic, and not about a knowledge base. We intend to separate these two strictly. In case a longpath can be inferred, it logically exists. If one or more of the intermediate nodes can be inferred to exist, they are potentially present in other information we are interested in integrating with it. Then, we can find new links the shortpath did not provide. That is the idea. Best, martin - IMHO the purpose of a long-path is to provide additional info (e.g. a date), but the shortcut cannot infer that - the purpose of a shortcut is to allow simpler representation, so why also infer a more complex but incomplete representation (no additional details)? - in cases when both shortcut and long-path are provided explicitly, an inferred long-path would be superfluous (duplicate), or a system needs to go through extra effort to somehow correlate the inferred to an existing long-path Cheers! Vladimir ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig -- Detlev Balzer, Mecklenburger Landstr. 5, D-23570 Lübeck Tel (+49/0)4502-8896495, Mobil (+49)0173-6231233 PGP Fingerprint 8E5F DCBD 2FC0 4058 86C2 3FEC 8D55 ACCD 2D71 8095
Re: [Crm-sig] groups and relations between persons
t;> >> -- >> >> -- >> Dr. Martin Doerr | Vox:+30(2810)391625| >> Research Director | Fax:+30(2810)391638| >>| Email: mar...@ics.forth.gr | >> | >>Center for Cultural Informatics | >>Information Systems Laboratory| >> Institute of Computer Science| >> Foundation for Research and Technology - Hellas (FORTH) | >> | >>N.Plastira 100, Vassilika Vouton, | >> GR70013 Heraklion,Crete,Greece | >> | >> Web-site: http://www.ics.forth.gr/isl | >> -- >> >> ___ >> Crm-sig mailing list >> Crm-sig@ics.forth.gr >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > ___ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > -- Detlev Balzer, Mecklenburger Landstr. 5, D-23570 Lübeck Tel (+49/0)4502-8896495, Mobil (+49)0173-6231233 PGP Fingerprint 8E5F DCBD 2FC0 4058 86C2 3FEC 8D55 ACCD 2D71 8095
Re: [Crm-sig] Call for Comments
Dear Martin and all,
while it is understandable that a recommendation from ICOM-CIDOC takes a
museum-centric view, this may obscure the fact that some communities
have been grappling with identity and identifiers for a long time.
Maximilian has mentioned the art trade, and objects described by
scholars not affiliated with a particular museum. Let me add another
example, which is that of papyrology:
http://papyri.info/hgv/65499/
What we see here is a chain of identifiers that had already been
compiled into a cumulative catalogue (the Heidelberger
Gesamtverzeichnis, HGV) before being published on-line.
Rather than pondering the idea of a persistent URI, I believe the
recommendation should encourage museums to associate their URIs with
metadata that carries all other known identifiers (if any). Any
institution or project with the necessary resources can then stitch
together related descriptions using a suitable predicate over a pair of
URIs.
This will work even if none of the recommendations outlined in sections
8 to 11 (except for the last paragraph in 11) can be followed. So why
not split up the document into one that describes the absolute
essentials (constructing URIs, resolving them to processable metadata)
and another which outlines policies for usage of these URIs by any party
that wishes to refer to them in their own LOD statements?
One personal remark concerning "leading national or community roles" as
mentioned in section 11: In my experience, these institutions are
sometimes all too willing to take over interesting ("buzzword") duties,
only to realize that their core staff is so busy with routine work that
the prestigious new task ends up on the desk of an apprentice.
Regards,
Detlev
Am 21.03.2011 17:02, schrieb martin:
> Dear All,
>
> Your comments on http://www.cidoc-crm.org/URIs_and_Linked_Open_Data.html
> will be most welcome!
>
> Best,
>
> Martin
--
Detlev Balzer, Hövelnstr. 11, D-23566 Lübeck
Tel (+49/0)451-8090344
PGP Fingerprint B5F3 6467 0615 1EB4 B602 8E41 DE70 8D59 0A8B BBD7
Re: [Crm-sig] ISSUE: CRM compatibility, VERY IMPORTANT
Dear Martin and all, just one remark concerning section 1.2: it appears as if the information integration environments (local information vs. integrated access) as defined in the draft do not include auxiliary information such as what exists in authority files, thesauri, reference sources, etc. I can imagine that some providers of such sources may also wish to make them available in a CRM compatible form. Let me briefly illustrate this with a hypothetical example. The various "Annales de l'industrie nationale et étrangère" by Le Normand and Moléon are reference sources typical for what is often used by museologists. Some electronic editions (e.g. http://cnum.cnam.fr/SYN/8XAE9.html) are available, however, only in human-readable prose form. Now let's assume that someone starts marking up the text so that individual statements about manufacturers and their products can be identified and parsed by machines. Let's further assume that the markup tags are mapped to CRM entities and properties. Users of the Annales could then decide if they continue to cite it as a bibliographical reference (where CRM compatibility will usually end) or to integrate a set of encoded statements from the Annales with their own descriptive metadata. In the latter case, both kinds of CRM compatibility (import/export and access) could become relevant. This raises the question if (a) the above use case is considered relevant, and (b) if it is adequately covered by the definition of integrated access systems as given in section 1.2 of the draft. Best regards, Detlev martin schrieb: Dear All, Attached my draft trying to flesh out in a text form the decisions made about CRM comaptibility in the last CRM-SIG meeting in May. This should become the instrument to distinguish false compatibility claims. It should be rich enough to cover all reasonable application cases. If not, we have to change it. Please read carefully, with respect to: a) Is this clear enough so that a good practice of validating CRM compatibility can be based on this b) Is it logically consistent c) Is it good English d) Is it functional and useful, is it attractive for providers and users, does it foster what we want to achieve with the CRM? Please comment. This text, your comments or rewritings will be the base for a decision on the CIDOC Conference if this text will be proposed to ISO as amendment to ISO21127. Only proposals submitted to this mailing list before the meeting will be discussed. Best, Martin ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig -- Detlev Balzer, Hövelnstr. 11, D-23566 Lübeck Tel (+49/0)451-8090344 PGP Fingerprint B5F3 6467 0615 1EB4 B602 8E41 DE70 8D59 0A8B BBD7
Re: [Crm-sig] Re.: [crm-sig] cidoc 4.2 in owl + alignment toDOLCE-Ultralight PLEASE RESPOND
Dear all, this is great. So I'll throw in yet another OWL representation that I have done in 2004 (and which it is a bit aged by now), for discussion and comparison: http://cidoc.ics.forth.gr/OWL/releasenotes349.html I agree with Martin's suggestion to nominate a coordinator and I'd be happy if Günther Goerz would volunteer for this effort. -- Detlev P.S.: Apparently, this situation is not too unusual: The MPEG-7 community has managed to produce four or five OWL representations of ISO 15938-5 largely independent of each other. And all of these had even been described in journal and conference papers. This is the information society at work ;) Mika Nyman schrieb: > Hello Guenther & others > > We have also done an OWL-implementation of the CIDOC-CRM 4.2 for our own > use. We also have a separate version that includes the latest version of > FRBRoo. Obviously I would be interested to participate in a co-operative > effort to arrive to an official OWL rendering of CIDOC-CRM and FRBRoo. > > It might be a good idea to publish draft versions of our efforts on a closed > wiki (=requiring login & authentication) and then have a mechanism for > on-line annotation. > > We have used Protégé 3.2.1 in our work, so our version can be opened with > Protégé. One option could be to distribute Protégé-versions and collect > annotations in a wiki. > > Best regards, > Mika > > > Synapse Computing Oy, Arabiankatu 2, 00560 Helsinki > i...@synapse-computing.com > +358-9-8569 9696 puh/tel > +358-9-8569 9595 fax > > > > -Alkuperäinen viesti- > Lähettäjä: crm-sig-boun...@ics.forth.gr > [mailto:crm-sig-boun...@ics.forth.gr] Puolesta Guenther Goerz > Lähetetty: 14. kesäkuuta 2007 1:35 > Vastaanottaja: martin > Kopio: crm-sig@ics.forth.gr; bernhard.schiem...@informatik.uni-erlangen.de; > Guenther Goerz > Aihe: Re: [Crm-sig] Re.: [crm-sig] cidoc 4.2 in owl + alignment > toDOLCE-Ultralight PLEASE RESPOND > > Dear colleagues, > > a while ago I wrote to Aldo whether he will continue to work on an OWL > version of the CRM aiming at an upgrade to version 4.2. At that time > he answered that he was not planning to do that and he sent me the > results of his work on version 3.4.9 to use it for further development > if we like to. I talked to Martin about that, expressing our interest > to pursue this issue further, but of course avoiding duplicate work. > Martin said that he was not aware of any other group --- including > FORTH already implementing or planning to implement a new OWL > version in the near future. So, we looked for a student and finally > found one who started to work on with a new implementation of 4.2 in > OWL as a study project several months ago. Now, he is nearly finished > and of course we will make the result of our work --- OWL code and > documentation (in German, sorry) --- available to the community as > soon as it is ready. Furthermore, we are planning to present it at > the Nuremberg workshop. So, I was a bit surprised by Aldo's last > message --- obviously communication in our community is sort of > suboptimal. Of course, I strongly support any effort to integrate > everything what has been done so far. Perhaps we should use the > Nuremberg workshop to set up a subgroup aiming at the implementation > of a reference version 4.2+ in OWL; obviously there are several issues > we have to agree on: problems in the current 4.2 document, > representational alternatives, alignment with DOLCE, etc. > Furthermore, we should nominate a coordinator to avoid duplicate work > in the future. > > Best regards, > -- Guenther > > Prof. Dr. Guenther GoerzFon: (+49 9131) 852-8701; -8702 > Univ. Erlangen-NuernbergFax: (+49 9131) 852-8986 > Institut f. Informatik 8/KI goerz AT informatik.uni-erlangen.de > Haberstrasse 2 ggoerz AT csli.stanford.edu > D-91058 ERLANGEN >http://www8.informatik.uni-erlangen.de/inf8/en/goerz.html > > > On 6/13/07, martin wrote: >> Dear Detlev, Aldo, >> >> I would much appreciate such an effort. We at FORTH would clearly > participate. >> Who else would like to participate? PLEASE RESPOND. >> I will put the idea on the issues list, and suggest to discuss details in >> the CRM-SIG meeting Dec. 4-7 in Nuremberg. >> >> Best, >> >> martin >> >> Detlev Balzer wrote: >>> Aldo Gangemi wrote: >>> >>>> Dear CRM specialists, I'd like
[Crm-sig] Re.: [crm-sig] cidoc 4.2 in owl + alignment to DOLCE-Ultralight
Aldo Gangemi wrote: > Dear CRM specialists, I'd like to point you at a new OWL version of > CIDOC 4.2, which I have produced for other purposes. It is based on the > official RDFS version, and besides the semantic translation, it only > includes a guess about the datatypes used in some CIDOC properties. > Please refer to file documentation for details (I've put it in a ftp > area of my lab, but if you find it useful, please copy it where > appropriate: > > http://www.loa-cnr.it/ontologies/CIDOC/cidoc_v4.2.owl I like the idea of expressing alignments between ontologies using OWL constructs such as equivalentClass. However, a straight automatic translation from RDFS to OWL misses the opportunity to formalize some of the (textual) definitions from the CIDOC CRM that cannot be expressed in RDF Schema. Wouldn't it be useful to include some more definitions (explicit and implicit) from the reference model? As an example, pairs of inverse properties are identified by the letters B and F appended to the numerical part of the property name. This is mnemonics for humans, but not easily processed by machines. However, it can easily be made processable by using the owl:inverseOf statement. There are further examples such as the disjointness of some classes (explicitly mentioned in the text) or the transitivity of some properties (e.g. P120F.occurs_before). One could go even further and declare P57F.has_number_of_parts as owl:FunctionalProperty, assuming that no instance of E19.Physical_Object can consist of different numbers of parts at a given time. How does the SIG think about a coordinated effort that would eventually result in an official OWL representation of the model? Some work has already been done and I think it shouldn't be too hard to reach a consensus on what to express in OWL language constructs, and what to leave out. Best wishes, Detlev
[crm-sig] A DAML+OIL representation of the CIDOC CRM
Dear all, I have recently prepared a representation of the CIDOC CRM using the DAML+OIL ontology definition language. DAML+OIL is basically an extension to RDF Schema (RDFS) that allows us to express some more features of the CRM definition in a way that can be under- stood by a number of ontology software tools. A description of the changes relative to the existing RDFS representation is given on the following page: http://thesauri.dbalzer.net/cidoc-crm/daml/ Please note that the DAML file is not quite up to date with ver- sion 3.4 of the CIDOC CRM. I am planning to supply a synchronized version within a few weeks, i.e. some time in June. Questions of further maintenance etc. are open for discussion. Best wishes, Detlev
Re: [crm-sig] CIDOC CRM poster?
Jakob Voss wrote: 62 Entities and 107 Properties are quite much (necessary, i suppose!) but they should fit on a square meter of paper. If they do not, how can they fit in one's mind! I haven't measured the physical size of the graph that I get when using the OntoViz plugin on Protege-2000. It may easily exceed 1 sq m when all properties are included. However, if you are satisfied with viewing the connectivity of class nodes one at a time, then I would recommend using this tool. To give you an impression of what this looks like, I have attached a snippet from a graph depicting the properties for class E52.Time Span. Crofts Nicholas (DAEL) wrote: P.S I believe some members of the SIG have considered transforming this graphic into a "mobile" - as an ontology training tool for the very young. I don't know how much progress has been made in this direction. ;-) Great suggestion! Best, Detlev
Re: [crm-sig] New CIDOC CRM Website
Crofts Nicholas (DAEL) wrote: The new web site is a great improvement. Clear and readable and uncluttered. True. I just noticed an unfortunate problem with the text formatting. It seems that the width of the text has been "fixed" at a width convenient for screens at 1024 x 768 pixels. (Since this is exactly the resolution I use it suits me fine.) However, with a screen set to a lower resolution, say 600 x 800, a lot of horizontal scrolling is needed to read the text, which is irritating. (With a higher screen resolution, a margin appears to the right of the text.) It would be preferable to free up the width of the text so that it reformats automatically to suit the client. This problem applies to pretty much all the text pages. I agree with Nick. Even though I use a screen width of 1200 pixels it annoys me if I am forced to set the width of the web browser to anything > 800 px, which means obscuring other applications that one would like to keep in sight. Best wishes, Detlev
[crm-sig] Implementation guideline: Addresses
Dear SIG, attached is a first draft of a guideline for dealing with addresses as CRM instances (see issue 65: Implementation guidelines for compounds). Martin noted that a person, corporation, etc., can have many addresses over time. Should we include some remarks on how to deal with the volatility (temporality) of addresses? Any comments, suggestions, corrections are welcome. Detlev <>
[crm-sig] Re: Naming proposal
martin wrote: Dear friends, I attach a study done by a student in my group about how identifiers for CIDOC CRM instances in RDF could look like. Before publishing it, your feed-back would be much appreciated, in particular, if you have knowledge of related work and other approaches. So this is about CRM instances in XML (not RDF). If we were dealing with RDF, then the first step towards disambiguation would have to address the CRM itself by defining a namespace URI for the RDF schema definition. Namespace prefixes can also be useful in XML and I wonder why this mechanism is not even mentioned in the report. The ex- amination of cataloguing rules remains vague and does not touch the more relevant parts such as the UNIMARC 8xx fields which are defined with concrete recommendations for naming the sources of authority records. Prefixing the contents of CRM property elements with names of authority documents has been proposed earlier. A major dis- advantage of this apprach is that XML parsers cannot separate prefixes from actual instance names without the help of external string-fiddling routines. The proposal in this paper would make the situation even worse by introducing further sub-element divisions that remain outside the scope of XML syntax. Subdividing XML elements using separator characters is generally a bad idea. After all, why do we have XML elements and attributes? Hierarchies of identifiers can be expressed as nested or sequential XML elements, making every single indentifier component accessible to an XML parser. Moreover, since authority references can vary between levels of the hierarchy, using attributes for source references would give us a clean data model that would just have to be added to the DTD. Using an example from the report (p.19), we could get something like EL medieval Greek Exchanging for using XML name- spaces would give us a simple extension mechanism, e.g. for instantiating subclasses derived from CRM classes such as ... Multi-level disambiguation could be done in various ways such as nesting or sequencing the disambiguating elements. Finding the most suitable representation with respect to processing (e.g. through XSLT) would be a worthwhile area of study. Best regards, Detlev
[crm-sig] Software tools and the CRM
Dear All, during the Copenhagen meeting Martin told me that there were several people who doubt that the CRM expressed in RDF could be processed by popular ontology editors such as Stanford Protege-2000. Since this is my favourite tool for hacking ontologies *including* the CRM, I think it might be useful if I give a short overview of software tools I know of that can be useful for modelling and application development using the RDF version of the CRM. All software packages are open source and freeware. Unless otherwise noted, these are Java applications that require a recent version of the JVM or JDK installed on your machine. Suitable Java packages are available free of charge from Sun or IBM. -- Ontology Editors Protégé-2000 from Stanford Medical Informatics (SMI) http://protege.stanford.edu/ This package has been around for several years, is actively maintained, and has a fairly large user base. Many people have contributed plug-ins that supply interfaces to other storage formats and KR software packages, visualization, and data acquisition facilities. Useful features that I have tried so far include a nice HTML documentation generator, the visualization package, a database storage backend using JDBC, and the facility to combine and merge several (partial) ontologies. XML and Schema support seems to be broken in the versions I have tried. As a modelling tool, Protege allows you to extend the CRM by creating sub-classes and sub-relations as well as instances. Instances are kept neatly separated from class and property definitions, e.g. by writing classes and properties to an RDFS file while aggregating all instances in an accompanying RDF file. Protege loads all recent RDF versions of the CRM without a problem. OilED from the University of Manchester http://oiled.man.ac.uk/index.shtml This is the current standard tool for editing DAML+OIL, an RDF-based KR language. It claims to be the "NotePad of ontology editors". OilEd loads RDF versions of the CRM (make sure to import them as RDF, not RDFS). To my taste, OilED is a bit more cumbersome to handle than Protege when used as a CRM modelling tool. Models can be verified with an external reasoning engine (FaCT) that comes with the package. Although I haven't played around with OilED to any significant extent, I assume that this can be useful as a shuttle in and out of DAML, a KR language in which an increasing number of terminologies, thesauri and ontologies are being published. OilED produces documentation in HTML similar to that obtained from Protege. Export options include simple RDFS, a SHIQ representation in XML from the Description Logics Implementation Group (DIG), and a simple vector graphics format. All export conversions seem to work well for the CRM. IsaViz from the W3C http://www.w3.org/2001/11/IsaViz/ This is announced as a "visual authoring tool for RDF". It will read the CRM in RDF and produce an awesome display of the entire model. When it comes to authoring, however, anything more complex than two or three RDF triples will be practically impossible to handle via the current user interface. Programmers' Toolkits Apart from the work done on RDF databases and query languages at ICS-FORTH (on which Martin may be able to comment), there are two packages that I find worth mentioning: Redland RDF Application Framework from ILRT Bristol http://www.redland.opensource.ac.uk/ This seems to be a solid library written in C with APIs for various languages, including Java. A query language is not included. However, there are several applications built on top of Redland, some of which provide database and query functionality. Jena RDF API from HP Labs, Bristol http://www-uk.hpl.hp.com/people/bwm/rdf/jena/ For those doing application development in Java, this one seems to be first choice. It comes with a very good tutorial. Working my way through the examples went smoothly and, of course, it digests the CRM in RDF without a hiccup. Finally, for those looking for an RDF parser for Visual Basic, there is a tiny package named Thea: http://www.semanticweb.gr/download.php?op=viewdownload&cid=3 This relies on Microsoft's XML3 DLL which is notorious for having difficulties with RDF syntax. CRM: no luck. - Detlev
